From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catonano Subject: Re: jquery 3.1.1 Date: Thu, 19 Jan 2017 23:47:00 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1142c418bff16505467a4f3f Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:32794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cULU0-0004FT-Sn for guix-devel@gnu.org; Thu, 19 Jan 2017 17:47:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cULTz-00080Q-0C for guix-devel@gnu.org; Thu, 19 Jan 2017 17:47:04 -0500 Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:36284) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cULTy-0007zt-Ld for guix-devel@gnu.org; Thu, 19 Jan 2017 17:47:02 -0500 Received: by mail-wm0-x231.google.com with SMTP id c85so14262419wmi.1 for ; Thu, 19 Jan 2017 14:47:02 -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 --001a1142c418bff16505467a4f3f Content-Type: text/plain; charset=UTF-8 2017-01-19 23:44 GMT+01:00 Catonano : > 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 > I mistakenly hit send. Sorry. But I had finished anyway ;-) --001a1142c418bff16505467a4f3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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= ,


<= /div>



=C2=A0
These pictures are very informative= indeed. I will try to be brief, but I quickly wanted to share
that I f= ind your efforts (and results!) amazing.

Thanks :-)


So= mething of note: a big chunk of the packages you classified as being 'b= roken' are
making me recall some (unpleasant) memories; F= rom my own crawling experiments,
which were not nearly as co= mplete as this one, I also ran into a lot of the same
show-s= toppers. In a very real sense, resolving node dependencies quickly devolves= into
resolving dependencies for most of the popular build sy= stems as well as plugins like
broccoli-funnel. What I am trying to get a= t here is that fixing and packaging these 448 packages
will likely= contribute a lot towards making an npm-enriched guix possible.

Yes. They're im= portant. 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 b= ody is empty in those cases).

These are those with "= nope" in the value

Others return error messages. I&#= 39;m affraid I overlapped some error conditions, though :-/
T= he errors I recorded are not completely accurate.

The err= ors. But the fact that they can't be downloaded stands.

Th= ey are still a bit too many but I'm afraid thhey have to be explored ma= nually
=C2=A0


There are 1314 packages with NO d= ependencies that could be used as starting points in porting Jquery into Gu= ix.
Here's the list
http://catonano.altervista.org/broken_packages.txt

These could probably make use of the npm importer I worked on earlier. D= o you make use of your own? Otherwase I'll get to
rebasi= ng my version on the current guix master branch.

I used some code that I wrote on p= urpose.
The file you want to consider is "n= pmjs.scm", the function is "populate-store" on line 178
=
The other files were there when I forked amz3's reposito= ry. They're theirs

=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">
=C2=A0


If there's anyone intere= sted, I can give you the data folder so you can try all the queries you wan= t on these data without having to to run this thing for a bunch of hours

If possible, yes please. Wha= t would be the most convenient way you to share this data?
=

=C2=A0
=C2=A0

In the future, I'd l= ike 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 SE= VERAL important packages in Nodejs.

So if someone wants t= o dedicate time to porting Nodejs stuff in Guix they will be able to select= most urgent packages to start from.

The same could be sa= id of broken packages taht affect several important packages.

The po= rting of Nodejs in Guix cannot be done with brute strength. A data oriented= approach can help, in my opinion.

<= div>Indeed.
=C2= =A0
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 th= e database.

Collecting a mantaining of datasets should be= freed of the client server model too. Not only the social media.
=

I have no idea wha= t you are referring to. Could you please elaborate a bit at a later point i= n time?

= Briefly, bitcoin keeps a ledger among a swarm of peers. They cooperate to k= eep a common datastructure, mantaining consense about the order of the tran= sactions, in a distributed way.

In my idea, some software= (based on gnunet ?) could be made such that every node would download a pi= ece of the graph and contribute it to te common data structure.

Because how will we deal with the fact that you could merge this gra= ph 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 peo= ple tha would like to collaborate ?

Coordination will be = needed.

The most immediate way would be with a central se= rver

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

Someth= ing similar to bitcoin would allow us to coordinate without the hurdles of = a pesky server

And this argument could be generalized. An alte= rnative to the client server model for collecting and mantaining datasets i= n general should be envisioned.

I s= ee proects for federating the social networks. But what about federating th= e backend machinery ?


I will elaborate in the future, though

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