***fds_ is now known as fds
<atgnag>What are the advantages of Guile over other scheme implementations? <davexunit>atgnag: Guile has an extensive C API for embedding or extending C applications or libraries. Guile also follows in the footsteps of Emacs to be a very hackable system, moreso than other less-dynamic Scheme implementations such as Racket. <atgnag>So, that C api isn't just a Foriegn Function Interface? <paroneayea>yow, looks like I need to make a distinction between #nil and '() in here, glad guile makes that possible... <paroneayea>(it's more obvious to me now why having distinctions between #f and #nil and even '() are good than when I started!) <atgnag>paroneayea: Why is that distinction good? <paroneayea>false, an empty list, and null are all different things <paroneayea>the whole thing I'm writing is a super advanced set of processing rules on top of json (json-ld) so I don't know *what* I'd do if I were in common lisp right now <paroneayea>atgnag: no, but there is a most excellent mode called geiser <paroneayea>atgnag: I see you're fairly new... welcome to #guile! <atgnag>Is Guile slow to compile, or am I just compiling something really large? <lloda>atgnag: building Guile itself? it does take a while <amz3>depends ... it builds fast on my machine <atgnag>lloda: No, I mean guile compiling scheme code. <amz3>I am thinking about the problem of my program. It's true that it would be simpler to be stateless, but performance will less good. And the high level API is mostly stateless. Fully stateless if transactions doesn't count as stateful <atgnag>guile4emacs, specifically, is what's taking forever to compile. <nalaginrut>yes it's slow for compiling guile-emacs, but finally it ends <nalaginrut>and works fine for me, although halts occasionally <amz3>nalaginrut: where is the article about the actor model ? :)) <nalaginrut>it's been a while, I hope it release first version soon <sneek>Sneeky bot running on Guile version 2.0.11 using bobot++ 2.3.0-darcs <nalaginrut>well it's easy to say, since Artanis hasn't released first stable too... <taylanub>please_help: the hashing functions for eq? and eqv? will usually use the memory address of objects. so this will start returning different hashes for objects after the moving GC moves around objects, so users can't rely on it. (hashtables themselves can be tightly integrated with the system and have their entries rehashed after GC.) <lloda>atgnag: compilation is very fast on stable-2.0, but can be slow on master, which has a fancier compiler that isn't finished yet afaiu <civodul>ah guile-for-emacs is 2.1, i think, which itself takes a long time to build <atgnag>Does it ever annoy you that golang files have the same file extension? <nalaginrut>atgnag: no one annoy, but many guys surprised that guile is compiled to golang ;-D <wleslie>and that guile's runtime is a 19x19 board on which small white and black stones are placed <atgnag>wleslie: You know, a virtual machine that worked that way might be interesting. Not very useful probably, but interesting nevertheless. <wleslie>it's similar to some regex runtimes. <nalaginrut>there're many continuations in erlang, but I wonder if they implement process with it ***adhoc_ is now known as adhoc
<nalaginrut>I've read the paper about compiling Erlang to Scheme, IMO, it's unnecessary to do so, I always think Erlang is Scheme actually, plus good coroutine design... ;-P <dsmith-work>nalaginrut: But the syntax! My head is too old to invest in new syntax. <nalaginrut>dsmith-work: well, if you transfer the syntax to s-expr (maybe in your brain), it's Scheme <wleslie>also [110, 97, 108, 97, 103, 105, 110, 114, 117, 116] <nalaginrut>of course, you have to have (ice-9 match) which is not standard of Scheme <wleslie>is not a very interesting way to represent a bytestring <nalaginrut>heh, I'm not going to write such a compiler to compile Erlang to Scheme, I'm just researching how to do efficient Actors in Guile <dsmith-work>nalaginrut: Yes, that's why scheme was invented, to tryout actors. <nalaginrut>ACTION still has terrible typo although he is using HHKB now... <nalaginrut>no mention we have delimited continuation now ;-P <davexunit>nalaginrut: Gerald J Sussman has an actor model implementation as well <nalaginrut>Erlang users may found it looks just like Erlang code, but just s-expr <davexunit>note that my code is a coroutine implementation, *not* an actor model implementation <davexunit>and the code was originally written by winog <nalaginrut>yes, I learned how to schedule delimited-continuations in principle <nalaginrut>my code is just prove of concept, but enough for explaining something <nalaginrut>anyway, new server core of Artanis will be far more complex... <nalaginrut>davexunit: yes, I need better scheduler design, agenda would be a good hint <davexunit>nalaginrut: my design could use some optimization. <davexunit>but I need to do the relevant benchmarking and test other implementations <nalaginrut>yes, it's better to take benchmark to see the performance of delimiter-continuations in Guile <nalaginrut>to my experience, the bottle neck is in scheduler, occupied almost 90% time <nalaginrut>but I don't think it's the problem of my scheduler, since it's very easy one, I think it's the overhead of stack copying in Guile <davexunit>I really like delimited continuations. really opens the doors for experimenting with new control flow operators. <davexunit>nalaginrut: yeah there's definitely overhead there. <nalaginrut>good news is the stack won't be copied till the delimited continuations is called <davexunit>I'm also interested to see what performance issues simply cease to be with Guild 2.2 <nalaginrut>davexunit: yes, you can control the granularity of the stack copying with prompt <nalaginrut>which is looks like an idea way to implement coroutines <davexunit>coroutines are the foundation of my game engine, despite users not really seeing them. <nalaginrut>davexunit: 2.2 support 10,000+ actors simultaneously <nalaginrut>and yes it's faster than 2.0 much while scheduling <nalaginrut>I've tested Erlang, seems 20,000 is a limit in my machine <davexunit>I have a suuuuper annoying bug in Sly right now that has completely drained my enthusiasm for hacking on it right now. <nalaginrut>davexunit: no hurry, I don't try 2.2 for Artanis too <nalaginrut>davexunit: if I were you, I would slow down and try another cool project <davexunit>nalaginrut: yup, been hacking on Guix instead <davexunit>but I'm so close to having monadic rendering combinators for Sly... <davexunit>that it's a bummer I have such a hard to find bug <davexunit>nalaginrut: write an artanis development package. <lloda>90c11483e630dd4f1d04feae9d370304237aa6cb in master broke control.test (ERROR: control.test: prompt in different contexts: ...), but I don't know how serious it is <nalaginrut>yeah, I'll write it when I release first stable one <davexunit>lloda: might be good to send to bug-guix, could be bad. <davexunit>nalaginrut: I keep a 'package.scm' file in my git repo that has everything needed to develop the project as well as install a development snapshot version <nalaginrut>my current OS is just too old, opensuse-12.2, not so nice to try some new packages <davexunit>nalaginrut: installing guix would give you access to tons of new stuff <davexunit>without interfering with the rest of the system <lloda>davexunit: I meant Guile master, I'm not the first to note the breakage, but anyway Guile master is wip <davexunit>nalaginrut: I released 0.1 and the basics work. <davexunit>I need to migrate my blog to it to dogfood further <nalaginrut>I may write alternative of tekuti with Artanis then, using git as DB, compatible with tekuti <nalaginrut>since I have to maintain my blog which is based on tekuti <nalaginrut>so I prefer try a tekuti compatible blog system with Artanis <davexunit>personally, I like static sites because there's nothing dynamic about a basic blog so serving static html pages eliminates several attack vectors (like SQL injection) and resists Slashdotting because there's no database to topple over. <davexunit>point being: there's no reason to have a dynamic web application backed by a database for something as simple as a blog. <davexunit>static sites greatly reduce maintenance and the possible attack surface for the server. <nalaginrut>wleslie: yes, but it happens when you just try to relax <wleslie>if you db driver *lets* you do sql injection there's already a problem <nalaginrut>of course, as a framework writer it's hard for me to relax ;-) <davexunit>wleslie: yes, of course, but I don't see how that invalidates my point that removing a dynamic web application from the equation reduces attack surface. <nalaginrut>unfortunately, seems only blogs could use static pages <nalaginrut>other service/application have to go dynamic way <wleslie>because if you can /spell/ git you know you shouldn't be building sql strings <davexunit>those are applications, different than websites. <wleslie>it's not a bug you can accidentally introduce. it's a bug introduced either by intense, directed stupidity, or by people who program by copying and pasting. <davexunit>wleslie: yes, many of us know that. this is going nowhere so I'm going to do other things now. <nalaginrut>wleslie: it's easy to say, unless you just pick up a framework rather than writing one. Sometimes you can't just close the door to prevent all the risk, you have to keep flexibility, provide mechanism for user to decide the policy <wleslie>sure. some languages and frameworks you've got to deal with do DB queries poorly. but if you're at that point, git is apparently already not an option for you. <nalaginrut>but it maybe not efficient for other service/application <ArneBab_>wleslie: with copying and pasting you mean what many people do nowadays: harvesting stackoverflow? <ArneBab_>^ I have the impression that intense directed stupidity is quite widespread <wleslie>indeed. or expertsexchange in the past. <ArneBab_>(especially with the fast changing landscape of frameworks where few people actually learn the stuff thoroughly) <wleslie>nevermind that there are frameworks that get it very wrong too. <ArneBab_>do you have a link for what django does wrong? <wleslie>alex gaynor gave an awesome talk 'why django sucks' ***thorwil_ is now known as thorwil
<wleslie>nope, the original video must have been one of those that disappeared. <nalaginrut>ACTION is testing 100,000 actors in 2.2, memory consuming is fair, the only problem is scheduling time is too long <wleslie>anyway, the query language has bits and pieces that are strings or schema objects or other things; leads to very strange exceptions if you get types wrong <wleslie>compared to eg sqla.core, which is fairly strongly typed. <nalaginrut>sql is suck IMO, but at present, we have to rely on sql for performance, ORM just solves part of problems <nalaginrut>I think SQL become a new high level assembly people have to face <nalaginrut>decades later, when people talk about 'assembly', they would say, oh JS? and SQL ;-) <amz3>a standart language like C or Java. That people need to know and interface with to try get things done <wleslie>ideally database tables would just be persistent maps/lists in the host language that need to be associated with transactions in order to be iterated over. <wleslie>maybe we'll be there before too long. <amz3>I'm wondering whether guile REPL server protects against injections <nalaginrut>wleslie: yes it could achieve, but doesn't looks like traditional ORM <nalaginrut>and to prevent mutability for reducing complexity, such mapping has to constrain something <nalaginrut>dunno, I wonder if people like such mapping when it become true <nalaginrut>as we know, people don't like the perfect thing, always <wleslie>I use sqla.core consistently rather than an ORM and I've been happy with how that feels <amz3>what do you think about a scheme database? <nalaginrut>amz3: it'll be cool, but I think the problem is how you handle relational mapping <wleslie>core is the right hand side - just a sql expression language <wleslie>you declare tables, build SQL queries, etc <nalaginrut>wleslie: I think SQLAlchemy ORM based on Core, no? <nalaginrut>if so, that's similar way what I did for Artanis, a low-level abstract level upon SQL <nalaginrut>I just want to build a new better abstract level base on it, but different from ORM <nalaginrut>(->sql select '(id names) from resource (where #:id another-id)) ... <nalaginrut>maybe need more condition keywords for convenient <ArneBab_>wleslie: one thing I learned: When something is really interesting, I have to download it, otherwise it will be gone (or no longer be listed in Google). <nalaginrut>anyway, many things need to do, I just need time <davexunit>nalaginrut: I've been wondering if perhaps record types would be better to use for SQL expressions <wleslie>ArneBab_: not sure if you heard a few years back when the site that hosted all the python talks decided to stop hosting talks from free software conferences <wleslie>ArneBab_: they didn't even tell the uploaders <nalaginrut>what we need is to auto generate accessor and setters <ArneBab_>I know what happened when the first free mercurial hosting site went down. <nalaginrut>davexunit: yes we could use record-type, but it'll looks like ORM <davexunit>nalaginrut: well, the point wouldn't be to make an ORM but to provide a way to represent the SQL AST <amz3>gremlin is relational DSL that looks like combinators <nalaginrut>davexunit: if so, for AST, I agree record-type is better <amz3>but it's targeted at traversing graphs <davexunit>nalaginrut: that's what you're doing with ssql, too. it's also an AST representation. <davexunit>the thing to be explored is which data structure lends itself best for the job. <nalaginrut>davexunit: I don't think so, ssql is too low-level, I wish there'll be one more abstract upon ssql <davexunit>what is the easiest to writing combinators to manipulate the SQL expressions? <nalaginrut>when we hit ssql, it's almost the assembly code gen part <amz3>I would be glad to see how SQL combinator look <davexunit>nalaginrut: you're confusing layers. the whole point of something like ssql is to provide a data structure for representing the SQL AST. <davexunit>that provides a format that eliminates SQL injection and such. <nalaginrut>davexunit: well, are we talking about ssql in Artanis? <davexunit>ssql is a term coined by one of the Chicken folks <davexunit>that uses sexps to represent SQL, like how SXML represents XML <amz3>In Aratanis, ssql is not an EDSL for SQL ? <davexunit>this is getting all too confusing, so I will bow out. <nalaginrut>in Artanis, ssql is a simple layer to help to format SQL string <nalaginrut>so there's no room to optimize with it just like an IR <nalaginrut>davexunit: I think you mean an IR for better optimizing & checking before code gen for SQL string <davexunit>it's about finding the right language to describe SQL expressions. <amz3>ah I did not understand then <davexunit>rephrased: is ssql the optimal data structure for this? <davexunit>that is a question I do not yet know the answer to. <davexunit>but I have concerns that make me want to explore alternative representations. <amz3>my point is: there is two layers 1) the layer that makes sql available in scheme 2) the layer the developper use to describe the queries <amz3>layer 1) avoid dealing with sql strings, layer 2 make it easy to use in scheme land <nalaginrut>IMO, it's better to design new IR for it, let ssql alone, we don't have to stick to it anyway <davexunit>we're all talking about different things and my efforts to make myself clear aren't working. <nalaginrut>well, cause I've been always confused to try to understand ;-) <amz3>datastructure or API is the same for me <amz3>by optimal, I suppose you mean, the most schemey way <davexunit>amz3: if a good format was chosen to represent SQL (your layer 1), then layer 2 is simply writing procedures that produce those objects. <amz3>nalaginrut: don't blame yourself ;) <amz3>layer 2 is the most difficult <davexunit>I feel the opposite. if you get layer 1 right, layer 2 becomes simple. <amz3>like i said, I'd like to see how those layer 2 looks like :-) <amz3>because I feel it's not simple <nalaginrut>since I treat the whole mapping process as a compiling process <davexunit>getting the means of combination right will take thought. <davexunit>let's say there's this: (select-all-from 'users) ;; => <sql> <davexunit>we'd want to be able to use the <sql> object output from one procedure as input to another <davexunit>like: (where (sql= '(users type) "admin") (select-all-from 'users)) <nalaginrut>but do you really think this way is better for users to understand? <davexunit>it provides an architecture for composing complex queries from smaller building blocks <davexunit>those made-up procedures above don't actually matter: it's all about the data structure that they operate on <davexunit>that I've left unspecified because I do not know what it is :) <davexunit>people would have the choice to use such combinators or hand-write their own queries using the AST data type. <nalaginrut>davexunit: I may keep this note till I make my mind clearer, and maybe it is necessary to prove that there's no contradict in such design <davexunit>I've done a lot of talking, probably too much, so I should sit down and actually write some code to demonstrate this sometime. <nalaginrut>davexunit: thanks for talking about it, I have to go to bed ;-) <davexunit>I think Ruby's Arel library (and ActiveRecord built on top of it) have the right general idea, but the result is lacking. <davexunit>with ActiveRecord it's possible to use raw SQL strings. :/ <davexunit>and sometimes you have to because of other limitatinos. <amz3>it's the same in Django at least <amz3>it's because it leaves the door open to sql features not supported by the library <davexunit>yeah, so it's reeeeeaaaaally important to come up with a data structure that can represent everything. <amz3>off-topic: I thrilled to see the new rendering api <davexunit>amz3: it will be similar to the picture language in SICP <davexunit>it will be lower-level. I'd like to implement the SICP picture language on top of what I write. <taylanub>what would Guilers say if a function is defined such that it returns a different number of values depending on the number of optional arguments it was given? like (hashtable-ref ht key) => result-or-#f, found-bool; (hashtable-ref ht key default) => result-or-default. this 1. hinders "forgetting" to handle the not-found case, 2. makes it trivial to explicitly fall back to #f by providing a <taylanub>default of #f, 3. allows for convenient branching via the extra value when one desires that instead of a default <amz3>I was going to say to use throw, but I know I you are going to say <amz3>what you are going to say <remi`bd>you can also do: (hashtable-ref ht key #:optional (default #f)) => result-or-default, found-bool <remi`bd>well, you can do the same with (hashtable-ref ht key . (default)) => result-or-default, found-bool <remi`bd>with a (let ((default (match default (() #f) (_ default)))) …) <taylanub>you can do that better with case-lambda, but the question was about the API, not the implementation <amz3>what about making `default` not optional? <taylanub>amz3: in that case it's difficult to disambiguate between the default return, and a value return where the value in the hashtable happened to be the same value as default <taylanub>you can avoid that by consing a "not-found" token on the spot then eq?-comparing to that object, but that's pretty ugly too <taylanub>another variant is defining a not-found record type globally in your code, ensuring through convention that instances of it can't ever land in a hash table (why would they?), then using that, which gives you a neat '(not-found? value)' predicate too, but well, it's still ugly overall <taylanub>what worries me about my solution is that it might confuse tools that expect every procedure to have a given signature w.r.t. its return values <davexunit>it's easy enough to roll your own quick thing that have the operations you need. <davexunit>or maybe use parameters, depending on the task. <paroneayea>I think parameters might be a bad idea for passing around the active-context in json-ld <paroneayea>I'm getting it to work without them, it's just a lot of work <paroneayea>implementing these json-ld algorithms has been trial by fire in figuring out how to transform big hairy imperative code into functional code <paroneayea>I have a feeling I'll be a lot more capable as a funcitonal programmer after this... assuming it all works... <daviid>I just duckducked 'SQL AST' a while ago, I don't have time but I'm interested by the subject and wish I could participate <daviid>reading the log, the conversation davexunit had with nalaginrut triggered my orm :) thought it woud help you to read it... ***dje is now known as xdje