Re: jquery 3.1.1

[Catonano <catonano@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5270 bytes --]

2017-01-19 23:44 GMT+01:00 Catonano <catonano@gmail.com>:

> 2017-01-19 22:07 GMT+01:00 Jelle Licht <jlicht@fsfe.org>:
>
>> Hello Catonano,
>>
>>
>>
>
>
>
>
>> These pictures are very informative indeed. I will try to be brief, but I
>> quickly wanted to share
>> that I find your efforts (and results!) amazing.
>>
>
> Thanks :-)
>
>>
>
> Something of note: a big chunk of the packages you classified as being
>> 'broken' are
>> making me recall some (unpleasant) memories; From my own crawling
>> experiments,
>> which were not nearly as complete as this one, I also ran into a lot of
>> the same
>> show-stoppers. In a very real sense, resolving node dependencies quickly
>> devolves into
>> resolving dependencies for most of the popular build systems as well as
>> plugins like
>> broccoli-funnel. What I am trying to get at here is that fixing and
>> packaging these 448 packages
>> will likely contribute a lot towards making an npm-enriched guix possible.
>>
>
> Yes. They're important. Some of them require you to be logged in in order
> to be downloaded. Or anyway the download fails with an error message in the
> response (the body is empty in those cases).
>
> These are those with "nope" in the value
>
> Others return error messages. I'm affraid I overlapped some error
> conditions, though :-/
> The errors I recorded are not completely accurate.
>
> The errors. But the fact that they can't be downloaded stands.
>
> They are still a bit too many but I'm afraid thhey have to be explored
> manually
>
>
>>
>>>
>>> There are 1314 packages with NO dependencies that could be used as
>>> starting points in porting Jquery into Guix.
>>> Here's the list
>>> http://catonano.altervista.org/broken_packages.txt
>>>
>>
>> These could probably make use of the npm importer I worked on earlier. Do
>> you make use of your own? Otherwase I'll get to
>> rebasing my version on the current guix master branch.
>>
>
> I used some code that I wrote on purpose.
> This is the repo
> https://gitlab.com/humanitiesNerd/Culturia
>
> The file you want to consider is "npmjs.scm", the function is
> "populate-store" on line 178
>
> The other files were there when I forked amz3's repository. They're theirs
>
>
>
>>
>>
>>>
>>>
>>> If there's anyone interested, I can give you the data folder so you can
>>> try all the queries you want on these data without having to to run this
>>> thing for a bunch of hours
>>>
>>
>> If possible, yes please. What would be the most convenient way you to
>> share this data?
>>
>
> Yes, here it is
> http://catonano.altervista.org/npmjsdata.tar.gz
>
> decompress it somewhere, then read amz3's instructions about their Culturia
> http://hyperdev.fr/notes/a-graph-based-movie-recommender-
> engine-using-guile-scheme.html
> http://hyperdev.fr/notes/somewhat-relational-database-
> library-using-wiredtiger.html
> https://github.com/amirouche/Culturia
>
>
>>
>>
>>>
>>> In the future, I'd like to run this thing on some other package and
>>> merge the graphs so I will be able to investigate which are the common
>>> fundamental dependencies for SEVERAL important packages in Nodejs.
>>>
>>> So if someone wants to dedicate time to porting Nodejs stuff in Guix
>>> they will be able to select most urgent packages to start from.
>>>
>>> The same could be said of broken packages taht affect several important
>>> packages.
>>>
>>> The porting of Nodejs in Guix cannot be done with brute strength. A data
>>> oriented approach can help, in my opinion.
>>>
>>> Indeed.
>>
>>
>>> The ideal would be to have something that, like bitcoin, coordinates a
>>> swarm in such a way that every node can contribute a tiniy bit of data to a
>>> common data structure, so all the nodes would have a complete copy of the
>>> database.
>>>
>>> Collecting a mantaining of datasets should be freed of the client server
>>> model too. Not only the social media.
>>>
>>> I have no idea what you are referring to. Could you please elaborate a
>> bit at a later point in time?
>>
>
> Briefly, bitcoin keeps a ledger among a swarm of peers. They cooperate to
> keep a common datastructure, mantaining consense about the order of the
> transactions, in a distributed way.
>
> In my idea, some software (based on gnunet ?) could be made such that
> every node would download a piece of the graph and contribute it to te
> common data structure.
>
> Because how will we deal with the fact that you could merge this graph
> with the one off CoffeeScript and in the same time I could merge it with
> the one of some other package ?
>
> And what about other people tha would like to collaborate ?
>
> Coordination will be needed.
>
> The most immediate way would be with a central server
>
> But I'm a nobody in the middle of nowhere, I don't want to set up a server
> and keep it on line
>
> Something similar to bitcoin would allow us to coordinate without the
> hurdles of a pesky server
>
> And this argument could be generalized. An alternative to the client
> server model for collecting and mantaining datasets in general should be
> envisioned.
>
> I see proects for federating the social networks. But what about
> federating the backend machinery ?
>
>
> I will elaborate in the future, though
>


I mistakenly hit send. Sorry. But I had finished anyway ;-)

[-- Attachment #2: Type: text/html, Size: 9933 bytes --]