IRC channel logs


back to list of logs

***jcowan_ is now known as jcowan
***fibratio` is now known as fibration
<duper>doesn't guile have a list flatten procedure?
<fibration>any guile-cv hackers here?
<fibration>never mind... i'm stupid... ;-)
***Raimondii is now known as Raimondi
<manumanumanu>Anyone have an idea why this won't work for guile2.2.3?
<manumanumanu>I suspect it has something to do with syntax->datum not being properly recursive leaving (fun car) as raw syntax
<manumanumanu>I get "unhandled constant <procedure car _>"
<ays>is there a package manager for guile? perhaps in development? I would like to contribute to something like that.
<galex-713>ays: there was guildhall I guess, and guix also can be used for that
<OrangeShark>guildhall, guix has a bunch of guile packages, and there is also something else that wingo worked on a bit that uses guix. I think it was called potluck
<galex-713>ah yeah potluck, forgot this one
<OrangeShark>not really sure what is the best direction for guile to go in for package management.
<ays>I think a standard package manager would really help guile's adoption. I am thinking of working on something like bundle in vim, but for guile.
<ays>*vundle in vim
<OrangeShark>ays: what is special about vundle?
<galex-713>I think something standard and specific but based on guix would be cool, especially if guix became better
<ays>OrangeShark: vundle uses github or other git-hosting sites as repositories for plugins. Perhaps something simple like that to pull down modules and update them using a vcs would be helpful.
<OrangeShark>ays: you can look into guix, it does have have the ability to pull from git hosting sites
<OrangeShark>and I think that might have been what potluck was aiming to do as well
<ays>OrangeShark: I am looking into potluck. Seems like something I can build on top of.
<duper>doesn't guile have a list flatten procedure somewhere?
<duper>thought it would be defined in the REPL by default but it's not
<OrangeShark>duper: I don't think there is one. A lot of list procedures were added in srfi-1
<galex-713>why not flatten? :o
<jcowan>galex-713: Olin didn't think of it, that's all
<galex-713>jcowan: ^
<jcowan>Olin Shivers, Scheme maven, author of scsh and SRFI 1 as well as other SRFIs
<galex-713>srfi are definitives and unexpendable right? :/
<jcowan>I'm not sure what that means. They are not standards. Some have a high degree of acceptance in the community, some have effectively zero acceptance beyond the author.
<ecraven>ACTION secretly thinks it would be great to have minor "updates" of some srfis, to add things like `flatten' to srfi-1
<jcowan>SRFI 1 is extremely well accepted, partly because its sample implementation is portable and efficient, partly because it's a comprehensive (though of course not all-inclusive) standard.
<galex-713>jcowan: I mean, if he wanted to add flatten to srfi-1, that wouldn’t work right? it’s like rfc: you publish them and if something went wrong, either you go with it for the rest of time or you make a totally new one right?
<galex-713>ecraven: agree
<jcowan>Mmm, somewhere between. Adding new functionality is beyond the scope. Errors can be corrected.
<jcowan>The only reason not to write a new SRFI is basically numerology
<amz3>what does that mean?
<amz3>jcowan: ^
<jcowan>People like the number 1 and it has cred. If you rewrote it today it would be 161 and everyone would say "161? WTF is that?"
<amz3>I am thinking about writing a srfi for a subset of rdf
<amz3>based on microkanren
<jcowan>Similarly, ASCII is ISO 646 and Unicode is ISO 10646. The resemblance helped to sell Unicode in its early days
<amz3>but that would be rather "big" compared to current srfi
<amz3>also I need to figure how datomic does recursive queries it seems like arcana knowledge or somethign, there is no doc about it
<amz3>or little
<jcowan>srfi 160 has 559 procedures in the API
<amz3>to be interesting it should implement a pluggable backend
<jcowan>granted only 43 unique procs * 13 subtypes
<jcowan>If it winds up being too big to review, srfi-editors@ (aka Art Gleckler) will let you know
<amz3>well, it's not big in terms of procedure, but in terms of knowledge, that's how at least I perceive it.
<jcowan>it's fine to break up something large into multiple pieces, as long as each is implementable (they can depend on others)
<amz3>yes I was thinking about that too
<jcowan>You can incorporate RDF documents by reference
<amz3>to submit the srfi for review I need to have the code + the writing?
<amz3>I need the code first, I did not even read the new microkanren book
<amz3>btw, fwiw, the ditital edition is readable
<amz3>btw, fwiw, the digital edition is readable
<galex-713>amz3: what is rdf exactely? I only understood from far away it was about semantics and AI and interesting but I never understood more
<galex-713>I barely understood XML Schemas beyond being an XML version of DTD having less or more stuff in some ways I guessed…
<amz3>those are different stuff XML and RDF
<amz3>both edited by W3C like HTML
<amz3>galex-713: rdf is a set of 4 tuples
<amz3>I mean a rdf database is a set of 4 tuples
<amz3>a set means that all tuples must be different
<galex-713>yes I know, that’s where I learnt about them
<galex-713>different like of different types?
<galex-713>why 4?
<galex-713>so it’s even a database thing?
<amz3>the canonical naming for the 4 tuples is (graph subject predicate object) but I prefer (collection uid key value)
<amz3>different like they have different equal?
<amz3>different in the sens of equal?
<galex-713>what’s the difference between uid and key then?
<galex-713>ah ok
<amz3>the original rdf is a 3 tuple called triple store, but 4 tuple is convenient to create the equivalent of sql tables
<galex-713>Damn I recently discovered Curv, through libfive, it’s astounishing :o
<galex-713>amz3: why?
<amz3>galex-713: to be able to put different things in different namespaces
<amz3>I use to use 'namespace' instead of 'collection'
<amz3>I am not sure about the naming still working on it
<galex-713>why not doing hierarchizable rdf databases then?
<amz3>it's more general that a hiearchy
<galex-713>how can it be more general?
<amz3>uid unique name of a document, where as key is an attribute, like a dictionary key, if you fetch all tuples that starts with ("posts" 42 _ _) then you have an assoc of keys and values
<galex-713>a graph?
<amz3>galex-713: yes
<galex-713>what would be 42 then here?
<galex-713>it’s like the 42th post?
<amz3>it can be used to build graphs
<amz3>galex-713: yes
<galex-713>then what is the key, if not the post number?
<amz3>that's exactly like 42th post
<amz3>key is the third component of the tuple
<galex-713>yeah okay, but what would it be used for, for instance?
<galex-713>I have difficulty understanding stuff without examples
<galex-713>without knowing its usage, I easily forget stuff and wipe it out my mind
<amz3>it can be for instance (('title . "RDF the easy way") (date . "2018/05/23))
<galex-713>oh wait
<amz3>galex-713: like everybody else !
<galex-713>me more I guess :P otherwise I wouldn’t say that
<amz3>coding helps to remember
<galex-713>you mean like there would be ("posts" 42 'title "RDF the easy way") ("posts" 42 'date "2018/05/23") ("posts" 43 'title "RDF the hard way") ("posts" 43 'date "2018/05/24")?
<amz3>galex-713: well, rdf is database it just that it looks fancy, because it's not oracle
<amz3>galex-713: yes
<galex-713>it seems to also have a more minimal base on which you build referential-like stuff like the rest
<amz3>galex-713: yes
<galex-713>except it seems like it could as well reimplement SQL or noSQL, and if you want performance you would likely implement it such as something not that RDF-y (more like SQL) actually, right?
<amz3>galex-713: it's minimal schema (the 4-tuple thing) is all you need to build more complicated structure
<amz3>galex-713: it's minimal schema (a set of 4-tuple thing) is all you need to build more complicated structure
<amz3>like scheme simple powerful primites ;)
<galex-713>why not 3? and how do you build graphs with the first element?
<amz3>galex-713: how would you name the 3 tuple then?
<amz3>(uid key value)?
<amz3>or something else
<galex-713>why 3-4? it seems a little bit arbitrary to me still… why not 5 or 2?
<amz3>(uid attribute value)
<amz3>galex-713: I already explained
<amz3>you need at least 2 to create assocs
<galex-713>or, (key value), and it would be an assoc list and we already use (and could use) that for a wide range of things
<amz3>but without a third element you can't name a particular set of assoc
<amz3>it's like (module variable key value)
<galex-713>amz3: what if you have another assoc which points to the other assocs?
<amz3>an assoc has a pointer/variable associated to it
<amz3>that's uid
<amz3>galex-713: it can only reference another assoc by identifying it using 'uid' or both 'namespace' and 'uid' if it's 4 tuple
<amz3>all that is explained nowhere i had to figure out
<amz3>so maybe it's not the best way to explain, but I am certain
<amz3>that 4 tuple is the best
<amz3>5 tuple becomes hairy
<amz3>just try to add another element to the following tuple ("post" 42 'title "RDF's future")
<amz3>it could be
<amz3> ("" "post" 42 'title "RDF's future")
<amz3>or something like that
<amz3>but like I said, it's complicated
<galex-713>couldn’t you have something like ("posts" (42 (title . "RDF the easy way") (date . "2018/05/23")) (43 (title . "RDF the hard way") (date . "2018/05/24")))?
<amz3>what you can do with a 3-tuple you can do with a 4-tuple, it's just that 4 tuples are more handy
<amz3>you mean, nest the tuples one inside the other
<amz3>build a hiearchy?
<amz3>building a hiearchy?
<galex-713>so you have a cons ("posts" . <pointer to assoc-list of posts>) in this assoc, conses of (uid . <pointer to assoc-list of attributes) and in this last one conses of (attribute . value)?
<galex-713>it would still be references
<amz3>something like that would be the most natural way to do using memory
<galex-713>but why not on disk?
<amz3>maybe, it will be the way to go
<galex-713>you just assing an id to each assoc-list…
<galex-713>oh, now I see
<galex-713>I think
<galex-713>so you just explicit the adress of the assoc-list making it *part* of the “tuple”
<amz3>but if you consider that you want to be able to tell which "post" have title "RDF the easy way" how would you structure your s-expr
<galex-713>and then you could add another member to make a doubly-linked list
<galex-713>so you can go back
<galex-713>I think I got it
<amz3>it's a good question
<amz3>basically it both because of on disk format and because you want to be able to query it
<amz3>otherwise, you simply 'write' the s-expr in a file and you don't need a database, but the database also allow for efficient querying
<galex-713>so, if we added adress, instead of (title . "RDF the easy way) it would be (posts->42 title "RDF the easy way")
<amz3>in a 3 tuple yes
<galex-713>no way it would be a true uid
<galex-713>(1234 title "RDF the easy way")
<amz3>well, it depends how you build uids
<galex-713>ande somewhere there would be (1234 . <adress of it>)
<galex-713>really, nor sql tables, nor rdf… are really intuitives to me, it’s just like you have so many ways of doing everything and there are too few constraints to help you choose
<galex-713>so is rdf the ideal minimal way of storing it?
<galex-713>or what would it be?
<amz3>galex-713: there is various constraint that leads to those choices
<amz3>galex-713: once you know the constraints you understand better the final result
<galex-713>I’d need to see implementation of sql tables (using multiple files and server, like mariadb, not sqlite) and rdf to understand I guess
<amz3>I think
<galex-713>Also I always wondered why sql is implemented upon filesystems instead of the other way around
<galex-713>like ZFS really got db-like features
<amz3>different constraint and needed features
<galex-713>why reinventing the wheel then? why not bringing these features to all files?
<amz3>yes, but you have limited transactions for instance
<amz3>to have better performance
<amz3>in some limited cases
<galex-713>also db are more generic and configurable, why not a generic system that could be casted/configured/compiled into something as specific and efficient as a filesystem but maybe more extensible or easy to grasp?
<galex-713>amz3: compared to what?
<amz3>"one program to rule them all" doesn't exist, it's like the universal physict theory of things
<galex-713>are you arguing for or against modularity here? not sure of understanding your quote
<amz3>not at all
<amz3>you say that you want a single software for both database and filesystem, is that correct?
<amz3>what is it then?
<galex-713>I said it would be cool to consider a filesystem as a specific occurence of a database, and build a filesystem-less database, and upon the database a filesystem
<amz3>you mean to write directly to the device?
<galex-713>or better layering: physical layer, adapting to used technology (network, hard drive, ssd, ram, etc.), then building database, and then a particular specialization of it that would be POSIX/ACL/SELinux/etc. filesystem
<galex-713>and then the filesystem would just be an occurence of it
<galex-713>because also you wouldn’t treat storage to ssd and hard drive the same
<galex-713>network is even more different
<galex-713>and ram too, but can have some things in common
<galex-713>but maybe I’m going too far
<amz3>one might say, filesystems are already an occurence of databases, the difference is that fs talks to device, whereas db talks to fs/kernel ... at the ned of the day they use the same algorithms
<amz3>I mean they share some algorithms
<galex-713>yes but filesystem works without database, whereas database is more general
<galex-713>this seems like a nonsense
<amz3>why do you think a database is more general?
<galex-713>because I can really easily imagine making a table of file with inode/type (directory, hard/sym link, file, device), content, and POSIX/ACL attributes and that would give a fs, maybe even an usable one
<amz3>of course, but it will not be efficient
<amz3>at least not as efficient as database
<galex-713>while for building a generic database for a fs, since the fs is clearly hierarchical, while the database may be a graph or just a mess of tables (then it would be 3D data: multiple tables, each table multiple rows, each row multiples values, but that’d be it) so I’d need to organize a standard to organize that in otherwise meaningly, hierarchical files with mostly leaf nodes…
<amz3>a database is just an optmized version of what you have in mind i think
<galex-713>amz3: no, because you added a layer
<amz3>galex-713: fwiw, I wrote a graph database on top the file systems , to bad I deleted the code this seemed too much like NIH
<amz3>galex-713: fwiw, I wrote a graph database on top the file systems , to bad I deleted the code this seemed too much like NIH syndrom
<galex-713>but when we build tons and tons of databases above filesystem, because for instance they would be the better way to archive emails, blog articles, caching stuff… having this directly above disk might be more efficient as well
<galex-713>and removing these from easy and intuitive access to the shell is sad
<amz3>there is reason softwares are not monolith but separated by layers of software that solvea particular task
<galex-713>amz3: NIH might be good if not too bad and tied to some community or langugae
<amz3>galex-713: yes, NIH is not that bad
<galex-713>amz3: but what is the particular task that filesystems do solve that databases don’t, that isn’t compatibility and easy access from the shell/file manager?
<amz3>galex-713: filesystems talks directly to hardware in the kernel
<amz3>that's kernel space software
<galex-713>excluded FUSE and hurd
<galex-713>and these are pretty neat
<amz3>this doesn't change the problem that each software solve a particular problem, delivring a particular API, that is possible to understand to solve other problems
<amz3>yes, if you ask why the fs is not a graph database, I would say, I don't know!
<amz3>maybe because hiearchy is easier to the mind
<galex-713>because graph has to cycle-collect
<galex-713>filesystem is not a graph because otherwise its reference-counting system would not work, you’d need a traversal garbage collector, it would be more resources consumed
<galex-713>it would be trivial to let the ability in any filesystem to let a directory be at the same time in several directories including a subdirectory of itself
<galex-713>including making a directory part of itself
<galex-713>probably somewhere there’s just a link(file) { if (directoryp(file)) error() […] }
<galex-713>to keep it from being done
<amz3>you have lot of imagination, too bad i did not read your code, yet!
<galex-713>yet, filesystem only is a giant database with only one table making an acyclic oriented graph (a tree)
<galex-713>because I don’t write much, especially, I don’t write much interesting stuff
<galex-713>not as interesting stuff as I think too
<amz3>how do you know?
<galex-713>these times, since a way too long time, each time I’d want to implement some subject of interest, I end up finding a reasonable and very relevant amount of documentation that might help knowing some features and shortcomings of the current stateoftheart, then distract, then forget and abandon and fail
<galex-713>because I mostly write nothing
<amz3>coding is hard let's go shopping
<galex-713>I tried to achieve a first year of CS this year, so the most “interesting” I might have done is writing tiny simple self-contained functions to do simple stuff but with bitfields/bitwise operations, branchless stuff and finding tail-recursive ways of doing stuff to get a decent excuse of doing stuff recursivly while it is advised not to
<amz3>did you pass the year?
<galex-713>and that’s not really that useful
<galex-713>dunno, I didn’t get the results yet
<amz3>well, you have to start somewhere
<galex-713>I still don’t know if I should study for the recovery exams or not…
<amz3>first year of programming i programmed a infix calculator
<amz3>not rocket science either
<amz3>today, I would build a forth to do the infix operation for me :D
<galex-713>and the larger stuff I wrote weren’t truely computing, only API, an almost finished translation from one (proprietary and high-level) API to a (free and low-level) other, for robotics, for having an excuse not to use the proprietary software asked to use in classroom, and some opengl exercises and project I didn’t almost abandon after not understanding some errors that the teacher weren’t able to understand either anyway
<amz3>even if I don't now what is forth vm
<galex-713>amz3: oh we got that too, I ended frustrated by the fact I could get difference performance depending on how I do error-checking, and wrote 163 cpp directives to make my code cover all the possibilities
<amz3>API is the new computing kiddo!
<galex-713>amz3: probably C, or even forth itself
<galex-713>no really it might be forth itself, there are plenty of decent forth compilers out there
<amz3>I mean what languages did you study?
<amz3>is it DUT or License that you do?
<galex-713>there was Visual Basic in the first semester, what a shame, don’t know if I want to talk about it
<amz3>VB? wtf?!
<galex-713>except I ended using Mono so not to use proprietary software like others, and did all my GUI using code instead of WYSIWYG editor
<galex-713>CS license
<amz3>oh ok
<amz3>still in Paris
<amz3>near Paris
<galex-713>no, Brest
<galex-713>Paris was too expensive
<amz3>I can understand that
<galex-713>now here you can get 30m² with 50€ per month
<amz3>500€ you mean
<amz3>that's nice
<galex-713>well, 250 actually, but I’m removing 200 of State allocations
<amz3>that's cool
<amz3>but you will have to move here
<amz3>in Paris one day
<galex-713>also everything is near, you almost never need the bus/tram/etc.
<amz3>to work at La Defence...
<galex-713>you can walk to everythere without taking more time, if you have to wait for the bus
<galex-713>why so?
<amz3>because that the righteous path of the french engineer :o)
<galex-713>I’m going to do either research, or nothing or some totally unrelated (to CS) eat-providing job
<amz3>I wish I did research, now it's too late
<amz3>I started a research project on wikipedia!
<amz3>on wikipedia university actually
<amz3>galex-713: do you want the link?
<galex-713>3G failed for some time
<galex-713>amz3: ^
<galex-713>[21:57:47] <amz3> because that the righteous path of the french engineer :o)
<galex-713>[21:57:58] <galex-713> I’m going to do either research, or nothing or some totally unrelated (to CS) eat-providing job
<galex-713>[21:58:10] <galex-713> engineering is a bad path for CS
<amz3>I started a research project on wikipedia!
<amz3>galex-713: do you want the link?
<amz3>galex-713: obv I was joking about La Defence thing
<amz3>yes it's in french
<amz3>I have read a few article and summarized them
<amz3>right now I am still working on building my own database for some reason :D
<amz3>NIH strikes back
<galex-713>guile-sql ? :p
<galex-713>amz3: seems loosely related to what you’re did before when you worked on a guile web search engine/scrapper?
<galex-713>with more real AI (that is less stats, but still)
<galex-713>I recall, talking of ingineering stuff, that the first time people told me about ocaml/coq/automatic proof, really they gave me the worst ever argument/selling argument
<galex-713>“It can’t be used to secure planes”
<galex-713>I really didn’t care
<galex-713>Then I realized automatic proof may harden private security, stabilize APIs, lessen the need of “maintenance”, break the dependency of program users on program maintainers, allow better entrusting of distributed calculation systems, etc.
<galex-713>like instead of having linux with an api changing any 2 months, you’d get something such as sel4 or something changing very not much such as TeX instead of the really instable and giant Firefox
<galex-713>maybe their funds came from Boeing
***Raimondii is now known as Raimondi