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