freenode/#lisp - IRC Chatlog
Search
23:59:54
dim
now working on having pgloader resilient to PostgreSQL operator interventions such as a restart... people have strange ideas about what is a bug sometimes, but at the same time, if we can handle it?
0:03:35
dim
the bug report reads: “When server restarts, or there is an issue with network connection, import fails with error:“
0:04:09
dim
(but then adds “but pgloader does not stop and is running infinitely” unfortunately, or it would have been great)
3:03:32
vtomole
beach: I think I understand your Sequence Functions paper. What should i do now? (with respect to SICL)
3:05:18
beach
There is a lot of obsolete code in the Sequences subdirrectory, so be careful what you believe.
3:06:14
vtomole
Is this the most recent code? :https://github.com/robert-strandh/SICL/tree/master/Papers/Sequence-functions/Code/Find
3:09:28
beach
As you can see, in Common, there is code for utilities, condition reporting and the sequence functions FIND, POSITION, and COUNT.
3:11:59
beach
You will need to make sure ASDF does not fail on warnings, and you need to increase the inline limit of SBCL to 10000 or so.
3:12:33
vtomole
How long should it take? I have "CL-USER> (ql:quickload :paper-sequence) To load "paper-sequence": Load 1 ASDF system: paper-sequence ; Loading "paper-sequence" ........."
3:14:13
beach
As you can see from the paper, the body of the function (i.e. the LOOP) is duplicated many times, maybe thousands, so the code is very large for the compiler to process.
3:15:30
vtomole
Yeah you mentioned that to me yesterday. I didn't register that it would be minutes, maybe 1 min max.
3:16:25
beach
But there are warnings that can't be silenced, and by default, ASDF fails when there are warnings, so you need to make sure that ASDF does not do that.
3:17:27
beach
Then you need to bump SBCL inline limit, or it just won't do all the inlining that is required for things to be fast.
3:23:27
beach
Then, in Test there are tests from the Paul Dietz test suite for ANSI Common Lisp. It would be good to make sure that the three functions implemented so far pass those tests.
3:25:51
beach
Probably the best thing to do is to rename the obsolete ASDF systems so that they mention "-obsolete" or something, and then rename the paper-sequence.asd system to sicl-sequence-support to correspond to the test system.
3:37:20
beach
Normally, if you are using SLIME, you have a buffer named *inferior-lisp*. Check it please.
3:37:25
vtomole
Ah yes " *GC-PENDING* = true *STOP-FOR-GC-PENDING* = false fatal error encountered in SBCL pid 13093(tid 140737256617728): Heap exhausted, game over. Error opening /dev/tty: No such device or address Welcome to LDB, a low-level debugger for the Lisp runtime environment."
3:38:14
beach
In your .emacs, do (setq inferior-lisp-program "/usr/local/bin/sbcl --dynamic-space-size 10000") or something like that.
3:44:51
beach
vtomole: Maybe the sequence functions require too much fiddling at this point. If you want to, I can try to find something that requires less of that. But then you have to give me time.
3:55:14
beach
Maybe something smaller is enough for the sequence functions, but I need that much for the bootstrapping process.
3:58:03
vtomole
Okay i set it in .emacs, and started a new REPL, I get "Heap exhausted during garbage collection: 8144 bytes available, 8208 requested."
4:09:13
vtomole
CL-USER> (room) Dynamic space usage is: 120,958,224 bytes. Read-only space usage is: 4,944 bytes. Static space usage is: 3,168 bytes. Control stack usage is: 8,888 bytes. Binding stack usage is: 1,072 bytes. Control and binding stack usage is for the current thread only. Garbage collection is currently enabled. Breakdown for dynamic space: 31,682,096 bytes for 1,980,131 cons objects. 29,299,584 bytes for
4:28:24
beach
vtomole: Try doing it outside SLIME first. Just start SBCL from a shell with the --dynamic-space-size that I showed you.
5:55:37
beach
I understand. I was wondering what kind of C or C++ projects you have planned for the future. You don't have to answer if you don't want to of course.
5:56:39
Murii
Right now I have a game framework written in C which uses Lua. A second scripting language will be nice. I also want to make a paint program (something basic like paint)
5:59:36
beach
For the paint program, I strongly recommend that you write it entirely in Common Lisp.
6:01:06
beach
It will give a much simpler architecture, and you won't have to deal with debugging combinations of different languages with different semantics.
6:12:53
beach
And, no, I don't think scripting is a good idea. It's a horrible kludge that is necessary because the main language chosen for the implementation is a static language that still uses 1960s linker technology so that it makes it impossible to redefine things at run-time.
6:13:50
beach
The obvious fix is to choose a better language for the main code base. It avoids lots of problems and makes it possible to do all kinds of scripting without any particular effort on the part of the developer.
6:15:51
beach
But you said C or C++, hence my comment. But again, this is #lisp, so Common Lisp is recommended over those languages. Common Lisp has a much more powerful object system than those languages do (unless they have introduced such things lately).
6:16:45
beach
I am curious, what is your reason for preferring C, C++, Java, or C# over Common Lisp?
6:16:47
axion
Indeed, and no other languages apart from Smalltalk implemented multiple inheritance correctly, if at all.
6:18:43
beach
Murii: The reason I am asking is, like I hinted before, that most of the time when people have such preferences, it's because of ignorance about Common Lisp. So I wanted to see whether that's the case or not.
6:19:49
beach
Murii: If you just happen to prefer any of those languages over Common Lisp, then that's fine of course, but it would be sad if you made the wrong choice for reasons of ignorance. You could pay a pretty hefty price for that in terms of productivity and/or application performance.
6:19:49
Zhivago
Not that I'm recommending the approach -- just to point out that there's nothing particularly special here.
6:21:56
axion
Murii: What beach said. I encourage you to actually see why this language family is still kicking today, which by the way is even older than C, a language that has very little reason to be used for large projects such as the aforementioned game frameworks you are working on. I also invite you to join our #lispgames channel for more information regarding this.
6:37:32
beach
Again, if you need more information about Common Lisp to make up your mind, don't hesitate to ask.
6:55:00
beach
Murii: Python is a bit special. For one thing, there is confusion about what is the language and what is the programming system. Languages are neither interpreted nor compiled, because they can be implemented either way.
6:55:35
beach
Murii: It has several implementations, and most of the modern ones compile to native code.
6:56:13
beach
Murii: The other possible confusion is that when some people hear "compiled", they think of "batch", i.e. an object file must be generated and then the application has to be linked.
6:56:50
beach
Murii: But most modern Common Lisp implementation compile on the fly in the interactive environment, which is what some people confuse with "interpreted".
6:57:36
beach
Murii: As a result, a good Common Lisp implementation generates code that is comparable in speed to that of traditional batch languages.
6:58:43
antoszka
Another confusion might arise with “batch languages” as some think they'd be interpreted glue languages like sh/bash/awk/tcl et caetera :)
6:58:46
beach
Murii: And that is exactly why I asked. Because some people choose (say) C++ because they think a typical C++ compiler generates MUCH faster code than a typical Common Lisp compiler. That just isn't the case.
7:01:15
beach
Well, I know very little about games, which is why I was referring to the paint program you mentioned.
7:01:27
Murii
This idea of making a language is stuck in my head and I can't let it go because then I'll feel bad
7:02:28
beach
That's fine. But it's also orthogonal to the choice of language for the paint application.
7:02:37
axion
I run the lispgames community. I encourage you to ask your questions in the channel I mentioned previously.
7:03:35
Murii
axion, I'm not sure exactly what to ask. I mean I know lisp is used for games(Naughty Dog use it)
7:03:45
axion
We have some very elaborate game libraries, for both 2D on the CPU and 3D games on the GPU.
7:05:25
axion
Murii: It's a simpler language, though not necessarily easier. Some argue it's focus is on acamedic use rather than practical.
7:06:05
beach
Murii: Yes, but that's usually the wrong thing to aim for. Obviously, a language with fewer features is also one that it harder to get things done with, at least in general.
7:07:35
beach
Murii: I used to use Scheme rather than Common Lisp, but I got real tired of having to invent my own object system and other crucial features for each application I needed.
7:08:11
beach
Murii: Furthermore, what I invented was not widely used (of course), nor portable to other Scheme implementations. I converted to Common Lisp and never looked back.
7:09:33
axion
Common Lisp is a real ANSI standard. Writing code using it means that your code will work decades from now, as has code written decades ago still does.
7:11:08
pjb
Actually, you can run in CL code written in the 60s! http://informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/wang.html
7:11:56
pjb
Not that those old programs be that fine in terms of style and structure, usually, but at least you can run them when needed.
7:15:25
loke
pjb: To be fair, that wasn't CL code from the 60's. It's Lisp code from the 60's that CL can run.
7:16:07
pjb
No, formally I said CL code written in the 60s, but I meant lisp code written in the 60s.
7:21:19
loke
I always found old lisp code to be written in a seriously bizarre way. However, once I start thinking of each line being a card, it makes more sense.
7:23:53
splittist
And when the next generation of programmers move on from a two-dimensional field of characters they'll wonder why we obsessed over indentation.
7:29:32
loke
Does Racket require a #something to initiate a custom reader? In CL, one could declare ╔ as a dispatching macro character, and thus avoid that.
7:32:28
loke
For this one in particlar: https://github.com/cicakhq/potato/blob/master/src/potato/db.lisp#L47
7:33:48
antoszka
https://github.com/shaunlebron/history-of-lisp-editing ← some interesting stuff, especially the PILOT paper from 1966 ;)
8:47:34
beach
Since SICL has first-class global environments, it would be possible to dissociate packages from their names and make the names part of the environment instead of being intrinsic to the packages themselves. Give me some advantages and disadvantages of this idea, please.
8:49:38
beach
Another possible idea is to allow for several different packages with the same name to co-exist, provided there is only one package with a particular name in a given first-class global environment.
8:52:07
beach
Dissociating package names would allow per-environment package nicknames. That way, one could have package names like com.informatimago.whatever and in an environment where such a package is referred to by some code, it could have a nickname specific to that environment.
8:57:43
flip214
beach: a possible disadvantage is recompilation and not-sharing things, so increased memory/cpu usage
8:59:42
p_l
it's definitely an advantage, especially if it provides an API and way to implement separate environment where you *do* want separation of code
9:00:14
p_l
I'd love to have 2+ environments in which I have code in supposedly same package but modified
9:00:32
flip214
beach: so, you'd basically have "chroots inside a lisp process", which sounds like a nice idea to me...
9:00:33
p_l
the reason is that I'd like to have one environment manipulate (without contaminating itself) the other
9:00:58
beach
p_l: Bike is planning to implement first-class global environments in Clasp so that he can compile the compiler, so I guess that's one example of what you are saying.
9:01:08
flip214
if that could be combined with cgroups (to limit CPU use -- memory use is a different beast because of the shared(?) heap), it would be awesome
9:01:10
ludston
phoe: I mean, having nicknames for packages is a change to syntax/intepretation, and no a change to how CL manages the packages
9:01:52
phoe
dissociating packages from package names is an internal change, in how the implementation handles and treats names
9:02:12
flip214
beach: that might want/need another feature... recompiling the compiler itself in a new environment, and if all tests run okay, promote that to be the new one being used "system" wide
9:03:07
phoe
I know, someone can trap parts of code from the old package as variables, closures and so on
9:06:45
beach
phoe: Funny you should mention that. Before going to bed, nyef had a long description about that difference in #clim.
9:07:30
flip214
so I imagine a tree of environments... a global one, a per-user one (using swank), and a subservient one where the compiler is being compiled...
9:08:49
flip214
and an environment may specify "its" parent/master environment to use for compilation?
9:10:04
beach
Notice, though, that the compiler has very few entry points. One could very well leave the environments alone and just import new entry points to the current environment.
9:10:42
beach
flip214: It is normal that I have been thinking of more things. I have had more time for it, since I invented first-class global environments in this form.
9:10:44
flip214
in CL, yes. in SB-*, there are some more -- and these might need to be swapped one-by-one, for the compiler developers.
9:11:18
flip214
I also fully appreciate the idea of having others brainstorm as well - there might be another good idea!
9:11:27
beach
But I still need feedback, because it is easy to get something like this horribly wrong by forgetting some major issue.
9:12:41
flip214
well, I'm thinking about whether it might be good or bad to have environments "separate" themselves, ie. break all links to other existing envs
9:14:52
flip214
I've got something nagging me about these multiple environment idea... but I can't put my finger on it yet.
9:15:27
flip214
how about being able to dump a single environment as a new image, or some hierarchy of envs? the whole system?
9:15:34
beach
I am thinking that things can go wrong in too many ways if first-class global environments are used with moderation.
9:16:10
beach
But, yes, if one starts allowing arbitrary graphs and arbitrary side effects to environments, then things could very well get complicated.
9:16:34
beach
I am thinking that things can NOT go wrong in too many ways if first-class global environments are used with moderation.
9:17:38
flip214
perhaps a FASL should then have some UUID, and if another env loads that too the image in memory can just reference all the read-only data from the previous load
9:17:59
beach
So I am king of thinking of starting out with a small list of features and a small number of environments. Time will tell what additional features might be desired.
9:18:50
beach
flip214: In fact I do something like that in the current bootstrapping process, but what I do is simpler, because the read-only stuff never leaves meo
9:19:42
flip214
oh, and if multiple environments ask for eg. HUNCHENTOOT, ain't that loaded from a FAL?
9:20:00
beach
flip214: That feature not only allows me to share all the complicated stuff like code of functions, but it also makes things much faster.
9:24:14
beach
So, it might very well be that Clasp becomes the first really usable Common Lisp implementation with SICL first-class global environments. :)
9:25:38
beach
ACTION is thinking that he really needs to hurry up and finish the CST library, so that he can then hurry up and finish Second Climacs, so that he can then, again, work on SICL bootstrapping.
9:28:44
flip214
brainstorming further on, I associate moving data from one env to another via S-expressions as a kind of replacement for the generic netlink layer and similar stuff...
9:30:55
beach
flip214: Some of these sophisticated ideas would have to be experimented with once I have a simple system up and running. It sounds like it belongs more on the OS level, so perhaps related to the LispOS that I have planned as one use for SICL.
9:31:17
flip214
and one of them allows to atomically xchg that env with another one == atomic replacement of the running kernel
9:33:07
beach
What meaning do you put into the word "kernel"? I am asking, because I avoid it in my LispOS specification, simply because it gives associations to a big blob of monolithic code, glued together by a 1960s-style linker.
9:33:56
flip214
I was thinking about the lowest-level support code that talks to the "real" kernel (linux, hurd, bsd, ...)
9:35:58
flip214
another idea: having an active env, "export" (really fork?) that into a separately running process; this might incur cleanups in both processes, then a big GC
9:37:47
flip214
beach: the thing is, I believe that processes _should_ be supported, because this is the major aggregation item for too many things right now.
9:38:37
flip214
and being able to limit eg. "that hunchentoot instance in that env" would be a very nice feature
9:39:50
beach
ludston: I am not sure what a shared library is in the context of a running Common Lisp system, other than a bunch of functions and data in memory.
9:41:21
ludston
beach: A potential negative branch is a "naughty" application playing with the internals of another lib which could corrupt everything else
9:41:27
flip214
and I'm not sure how easy it is to have memory limits, too -- see also https://sysdig.com/blog/container-isolation-gone-wrong/ for a similar linux-kernel problem
9:42:40
beach
ludston: Oh, I should have warned you. I am incapable of doing my thinking relative to dumb systems like Unix derivatives. I am thinking about safe systems like Common Lisp.
9:42:42
flip214
beach: just as an idea -- how about having multiple heaps, and then share _one_ heap between multiple processes if they need to talk to each other? yeah, lots of caveats.
9:43:42
flip214
and especially the compiler writers need to produce low-level "data" == code - and a bug in code-generation will kill the whole "unix process"
9:45:11
flip214
beach: while I understand your wish about a single memory space, and see the advantages, I'm concerned about the implications. I've seen too many behemoths that tried to be the one-right-thing,