|Subject:||Re: jquery 3.1.1|
|Date:||Thu, 19 Jan 2017 23:47:00 +0100|
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' aremaking 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 sameshow-stoppers. In a very real sense, resolving node dependencies quickly devolves intoresolving dependencies for most of the popular build systems as well as plugins likewill likely contribute a lot towards making an npm-enriched guix possible.
broccoli-funnel. What I am trying to get at here is that fixing and packaging these 448 packagesYes. 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 valueOthers 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
Here's the listThere are 1314 packages with NO dependencies that could be used as starting points in porting Jquery into Guix.
/broken_packages.txtThese could probably make use of the npm importer I worked on earlier. Do you make use of your own? Otherwase I'll get torebasing my version on the current guix master branch.I used some code that I wrote on purpose.This is the repo
humanitiesNerd/CulturiaThe file you want to consider is "npmjs.scm", the function is "populate-store" on line 178The other files were there when I forked amz3's repository. They're theirsIf 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 hoursIf possible, yes please. What would be the most convenient way you to share this data?Yes, here it is
org/npmjsdata.tar.gzdecompress it somewhere, then read amz3's instructions about their Culturia
CulturiaIn 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 serverBut I'm a nobody in the middle of nowhere, I don't want to set up a server and keep it on lineSomething 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
|[Prev in Thread]||Current Thread||[Next in Thread]|