Re: jquery 3.1.1

[Catonano <catonano@gmail.com>]

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

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


> But that's more than I can handle, anyway.
>>
>
> I am already thankful
>
>>
>> I'd like to talk about the stumbling blocks I run into to discuss Guile
>> and my knowledge of it.
>>
>> For example, I can't use that thing in the autotools that processes
>> configure.am files so I just forked amz3's project and added my files in
>> there. As guests. Thanks amz3 !
>>
>> I'd also like to describe te screw ups in the format I put the data into.
>> I realized my mistakes when hours of crunching had already been done.
>>
>> They can be migrated to a better format though
>>
>> If you don't mind, I will discuss these issue in the future, not now.
>>
>> The code is here
>> https://gitlab.com/humanitiesNerd/Culturia
>>
>> One last fun fact: while I was watching the output flowing in my
>> terminal, I saw a package called
>>
>> "broccoli-funnel"
>>
>> No, really. It's here
>> https://registry.npmjs.org/broccoli-funnel
>>
>> Ok, that's all for now.
>>
>
> Thanks again for your efforts on this. I am looking forward to working
> with your data.
>
> Regards,
> Jelle Licht
>

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