From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catonano Subject: Re: jquery 3.1.1 Date: Thu, 19 Jan 2017 23:44:52 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114355a61457af05467a48e3 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cULRw-0003QB-Gg for guix-devel@gnu.org; Thu, 19 Jan 2017 17:44:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cULRu-0007C2-91 for guix-devel@gnu.org; Thu, 19 Jan 2017 17:44:56 -0500 Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:36643) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cULRt-0007Bp-UG for guix-devel@gnu.org; Thu, 19 Jan 2017 17:44:54 -0500 Received: by mail-wm0-x229.google.com with SMTP id c85so14203027wmi.1 for ; Thu, 19 Jan 2017 14:44:53 -0800 (PST) In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Jelle Licht Cc: guix-devel --001a114355a61457af05467a48e3 Content-Type: text/plain; charset=UTF-8 2017-01-19 22:07 GMT+01:00 Jelle Licht : > 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 > --001a114355a61457af05467a48e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2017-01-19 22:07 GMT+01:00 Jelle Licht &= lt;jlicht@fsfe.org= >:
Hello Catonano,




=C2=A0
Th= ese pictures are very informative indeed. I will try to be brief, but I qui= ckly wanted to share
that I find your efforts (and results!) amazing. <= br>

Thanks :-)
=
=


Something of no= te: a big chunk of the packages you classified as being 'broken' ar= e
making me recall some (unpleasant) memories; From my own cr= awling experiments,
which were not nearly as complete as thi= s 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 tha= t fixing and packaging these 448 packages
will likely contribute a= lot towards making an npm-enriched guix possible.

Yes. They're important. Some of the= m require you to be logged in in order to be downloaded. Or anyway the down= load fails with an error message in the response (the body is empty in thos= e cases).

These are those with "nope" in the va= lue

Others return error messages. I'm affraid I overl= apped some error conditions, though :-/
The errors I recorded= are not completely accurate.

The errors. But the fact th= at they can't be downloaded stands.

They are still a bit t= oo many but I'm afraid thhey have to be explored manually
=C2=A0
=


There are 1314 p= ackages with NO dependencies that could be used as starting points in porti= ng Jquery into Guix.
Here's the list
http://catonano.= altervista.org/broken_packages.txt
These could probably make use of the npm importer I wor= ked 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.
The other files were there when I forked amz3's repository. They'= re theirs

=C2=A0
=C2=A0


If = there's anyone interested, I can give you the data folder so you can tr= y all the queries you want on these data without having to to run this thin= g for a bunch of hours

If = possible, yes please. What would be the most convenient way you to share th= is data?

=C2=A0
=C2=A0

<= div>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 fun= damental 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.
<= div>
The same could be said of broken packages taht affect several impor= tant packages.

The porting of Nodejs in Guix cannot be done with bru= te strength. A data oriented approach can help, in my opinion.

Indeed.
=C2=A0
The ideal would be to have something that, like bitcoin, coordin= ates a swarm in such a way that every node can contribute a tiniy bit of da= ta to a common data structure, so all the nodes would have a complete copy = of the database.

Collecting a mantaining of datasets shou= ld be freed of the client server model too. Not only the social media.
<= /div>

I have no ide= a what you are referring to. Could you please elaborate a bit at a later po= int in time?

Br= iefly, bitcoin keeps a ledger among a swarm of peers. They cooperate to kee= p a common datastructure, mantaining consense about the order of the transa= ctions, in a distributed way.

In my idea, some software (= based on gnunet ?) could be made such that every node would download a piec= e 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 t= he one of some other package ?

And what about other peopl= e tha would like to collaborate ?

Coordination will be ne= eded.

The most immediate way would be with a central serv= er

But I'm a nobody in the middle of nowhere, I don&#= 39;t want to set up a server and keep it on line

Somethin= g similar to bitcoin would allow us to coordinate without the hurdles of a = pesky server

And this argument could be generalized. An altern= ative 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
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
But that's more than I can handle, anyway.
<= /blockquote>

I am already thankful

I'd like to talk about the stumblin= g blocks I run into to discuss Guile and my knowledge of it.

<= div>For example, I can't use that thing in the autotools that processes= configure.am files s= o 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 h= ours of crunching had already been done.

They can be migr= ated to a better format though

If you don't mind, I w= ill discuss these issue in the future, not now.

<= div>One last fun fact: while I was watching the output flowing in my termin= al, I saw a package called

"broccoli-funnel"


Ok, that's all for now.

Thanks again= for your efforts on this. I am looking forward to working with your data.<= br>
Regards,
Jelle Licht

--001a114355a61457af05467a48e3--