guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: jquery 3.1.1


From: Catonano
Subject: Re: jquery 3.1.1
Date: Thu, 19 Jan 2017 23:47:00 +0100



2017-01-19 23:44 GMT+01:00 Catonano <address@hidden>:
2017-01-19 22:07 GMT+01:00 Jelle Licht <address@hidden>:
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.
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?

 
 

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 ;-)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]