freenode/#lisp - IRC Chatlog
Search
15:48:50
warweasle
Memory management, garbage collection, thread protection, etc. At least at the low level.
15:49:55
phoe
except Lisp gives you some more things like a sane type system that helps you actually not commit a crashing mistake
15:50:05
on_ion
i was not referring to compiler v. interpreter, not part of current context of topic, but implementation v. implmntation
15:50:35
phoe
warweasle: also "Swapping out function calls as you change the functions" is already being done in implementations
15:51:27
phoe
but redefining functions at runtime already happens well enough in multithreaded implementations
15:51:52
warweasle
OK...now I'm tracking. It's almost like having two lisps, a high level and low level.
15:53:32
phoe
the best way of not having direct acccess to memory is not having direct access to memory
15:53:44
beach
warweasle: Just as in Common Lisp, you can't access an arbitrary byte of memory, you couldn't do it in the LispOS I am planning either.
15:54:10
beach
warweasle: But it is not because there is a kernel. It is because you are simply not allowed to write code that accesses memory directly.
15:54:16
phoe
if your Lisp REPL does not give you access to any stuff like dereference-pointer or such, you simply can't do it
15:54:31
phoe
it's hard to dereference a pointer if there's no pointer and there's no dereferencing API
16:01:29
beach
nirved: Again, I seriously doubt that it would be widely adopted. I am a researcher, and I want to show that we can do better than we have been doing for the past half a century or so. If Nvidia does not buy that, then there is nothing I can do about it. As long as I can show that IF NVIDIA HAD ACCEPTED IT, then we would be better off, I am satisfied.
16:03:59
beach
nirved: I am one single person, and I can't possibly rewrite all the applications I use on a daily basis in Common Lisp so that I can ditch my GNU/Linux system. So for the foreseeable future, I would have to use both systems simultaneously. One way to do that is to run the LispOS as a Linux process. Another possibility would be to run it in some virtualizer.
16:04:54
nirved
beach: i mean, will there be a way to extend it, supporting different kind of devices
16:05:15
warweasle
beach: I might have to write embedded code in the future. So that's why I'm asking so many questions.
16:05:25
beach
Because of first-class global environments, there could very well be one environment, inaccessible to the ordinary user (would require "system" privileges) that would be able to access memory directly.
16:05:26
beach
But that functionality would not be accessible to ordinary users in "user" mode. All of that is totally unimportant for the overall safety of the system. It still has nothing to do with a kernel. Such a privileged environment might also be
16:06:26
warweasle
But parts of it might be useful. You never know what might give you an idea that simplifies a project immensely.
16:06:42
beach
... might also be used for compiler-backend stuff that should not be accessible to the application programmer.
16:07:23
nirved
beach: i looked a bit at the GC, there's Staccato, don't know if it's relevant to lisp: https://researcher.watson.ibm.com/researcher/files/us-groved/rc24504.pdf
16:08:04
warweasle
*IF* I could bootstrap an implementation of lisp onto the machine, then I might have a lot of fun poking the device.
16:08:44
beach
nirved: But GC is very complicated in terms of predicting performance, so it's too early to determine whether my plan will work out.
16:16:09
on_ion
beach: nope sorry, just wondering if this was all common lisp, which would need a lot more than bare metal core runtime
16:16:11
jackdaniel
if we insist it is CL-only channel (not lisp-in-general-related-channel), then it might be a case
16:17:16
jackdaniel
beach: ffi is part of *existing* implementations, but whatever. if people around are happy I have nothing against. just dropped my 2 cents
16:18:12
on_ion
dlowe: well, wait are you really asking? how could someone run CL without a CL implementation ?
16:18:40
beach
on_ion: You would build an executable on a different system with an existing Common Lisp implementation.
16:18:57
on_ion
yes but, you still need that CL implementation alive and kicking to have a lisp system, no?
16:20:11
jackdaniel
on_ion: same comes to any program (except ones writtenn in hand machine code) – you need kicking C compiler to build C compiler (or Linux kernel)
16:20:34
random-nick
there are already CL implementations like SBCL and CMUCL that bootstrap from an existing implementation
16:20:36
White_Flame
if you need an x86-hosted C compiler to generate an ARM program, does that mean the program has a requirement of x86? not really
16:20:38
on_ion
jackdaniel: a CL system requires the full CL system to be a CL system, no? C executables dont need C compilers
16:21:12
on_ion
a running lisp system needs a living lisp VM and all the things, no? am i missing something?
16:21:46
jackdaniel
on_ion: I said that you need C compiler to build C compiler for a new platform for that instance. I think you are a bit confused with a few different (though slightly related) topics
16:22:23
warweasle
beach: But I used them to keep change logs and to remotely access them using UUIDs.
16:23:38
warweasle
beach: Sort of a "self describing" data, but with a few basic interfaces for text, rich text, image, vector, sound, etc.
16:25:36
on_ion
even if one could gut out the things one does not want/need, to get CL running on bare, and work on one's own OS ideas from there
16:26:12
on_ion
is there a plain/vanilla bare-metal CL implementation that all the OS experiments could use ?
16:27:01
beach
on_ion: I would much rather start with a Common Lisp system NOT running on bare metal but that I can run with proper debugging support, etc.
16:27:51
on_ion
beach: true, im not knowledgeable in their abilities. i know that NASA had some lisp thing going on with a rocket which definately was bare metal
16:30:04
White_Flame
OSes generally "accept" a binary footprint of machine code & data with start address & links to system stuff
16:30:41
on_ion
White_Flame: yeah. so im just wondering why there is a llvm->CL transpiler if one cannot simply execute the llvm like on a regular OS
16:31:23
on_ion
im curious because beach mentioned security also , which i am interpreting a bit like a CL sandbox
16:33:56
Bike
I think beach's particular design doesn't really allow arbitrary binaries in the same way.
16:35:59
on_ion
fasl is what is emitted and loaded after sbcl compiles lisp, right ? same practical purpose as if it were a "CL bytecode" ?
16:36:47
White_Flame
basically, what you're asking is the equivalent of running in random patterns in a vocabulary minefield ;)
16:36:52
Bike
sbcl fasl files contain machine code, not bytecode. but yes, it's the output when you compile a file.
16:38:07
jackdaniel
for instance ECL's "FASL" files are in fact shared objects (as *.so libraries) on Linux
16:38:55
beach
on_ion: Traditional code that uses the full address space would have to be run in a separate process, presenting itself as a single Common Lisp function.
16:38:56
beach
Such code could not directly access Common Lisp objects in the system, but they would have to use something similar to file descriptors. That would be just as inconvenient as it is on Unix systems now, so it would probably be uncommon.
16:39:20
froggey
beach: no, I intend to use an in-image filesystem as the primary fs. there's a basic proof of concept already (the local filesystem), but I haven't really nailed down any details
16:42:13
beach
froggey: It would be great if you could plan to come to ELS in Genoa. We could chat about things like this.
16:44:00
froggey
my current focus is getting the mezzano backend for mcclim into an acceptable state for demo 4
16:44:09
skidd0
Hey guys. I'm attempting to build a small command line program on Linux in Common Lisp. Does anyone have experience with distributing small lisp programs? And, any favorite libraries for handling command line args? There seems to be a lot of options out there for both questions, so, I'm looking for community input
16:45:09
White_Flame
skidd0: I've deployed really small initialization utilities as standalone executables. They're obviously still laughably large in filesize for what they do, but it's nice to include all the libraries & lisp knowledge that the main application uses
16:45:47
rpg
skidd0: I have heard different things about how easy it is to move buildapp apps around. I believe that there can be issues with shared libraries when you move them, but I'm afraid I do not understand these issues myself\
16:46:01
froggey
on_ion: that's a bit of a cheat, it's telnetting to the nethack server on nethack.alt.org
16:46:28
skidd0
well so has anyone build 'apps' that are easy for other (non-lispers) to download and then execute/use?
16:46:45
jackdaniel
rpg: basically when you dump sbcl image with foreign libraries loaded, it tries to load them from the very same location when you start the application
16:46:56
jackdaniel
so in order to avoid that you need to close all shared libraries before dumping image
16:47:45
rpg
jackdaniel: I have never built anything with FFI that uses buildapp, so that shouldn't be a problem for me. I was wondering if there were any shared libraries that SBCL itself would load.
16:47:57
froggey
there's no support for running arbitrary native code though, everything must conform to the mezzano abi for the GC
16:48:28
jackdaniel
only those which you load yourself. the trick is that it assumes that libraries loaded when you dump image will be at the exactly same location
16:48:59
froggey
on_ion: yes, just basic framebuffer support right now. the video mode is set by the bootloader & not changed after that
16:49:51
jackdaniel
rpg: (of course that applies to the libraries your dependencies load). also there is a trick with cl+ssl – you need to call also "reload" function, because some structures must be initialized in the foreign library
17:10:18
White_Flame
you need to figure out what sort of file structure it wants around it, or if it's purely self contained
17:20:27
dlowe
White_Flame: it kind of is, because our lisp systems don't use libdl to automatically link all the shared library code back up
17:21:03
White_Flame
and yeah, it's a more complex space than windows or osx might be for these particular points
17:22:13
skidd0
man the more i dig into programming, the more i realize how pointless paying tuition is
17:23:50
White_Flame
programming is still a craft. there's no major thread of academics that teaches it
17:24:06
dlowe
I dropped out of college and when I compare my career with my programming peers that stuck with it, it was *much* harder for me. Those fundamentals are great to learn up front.
17:24:07
White_Flame
cs = the "science" of computation. ce = building hardware. software engineering = project management
17:25:09
White_Flame
dlowe: yeah, I'm in the same boat (though I didn't willingly drop out; I got "financial aid"ed out of school :-P)
17:27:17
White_Flame
skidd0: if you want to get out of school, then push hard on actually getting industry contacts and job offers
17:28:04
White_Flame
but when it comes to security, I think the uni papers are still a barrier to entry
17:29:50
jackdaniel
ACTION thinks this discussion steadily moves offtopic (that is in #lispcafe direction;)
17:51:22
White_Flame
it's always best to just use the default facilities first and get a hang of what's going on and what needs to be done
17:51:34
White_Flame
then you can make better decisions on what features you need if you actually do need something more complex/bundled
17:52:05
Xach
phoe: i have two hard drives and a fast computer running them but i have been away from home for a week so there has been no progress. i am optimistic i can build something soon. i really would like to get my old hard drive recovered though. that might involve shipping it somewhere.
17:53:55
Xach
I was once very disciplined about backups. I have been punished for backsliding into laxity.
18:21:27
on_ion
i sometimes wish that we had something like ChangeSets for lisp images, like squeak has for its smalltalk images
19:42:02
on_ion
phoe: er, already mentioned those earlier. intent of comparison to squeak smalltalk ChangeSets, those are portable across implementations and machines. they are essentially source code diffs.
20:02:29
pjb
Most often you cannot apply such patch, even on the same implementation and machine, when you try to apply them on a different version.
20:21:38
jmercouris
I'm reading this article here: http://joaotavora.github.io/sly/#A-SLY-tour-for-SLIME-users about SLY
20:21:49
jmercouris
and I'm wondering, any SLY users in here? can you tell me why you prefer it to Slime?
20:25:38
jmercouris
I don't see anything that can't also be done in slime, but maybe I'm just missing some things
20:27:44
Bike
this intro is starting with a bunch of stuff slime doesn't have, so maybe i'm misunderstanding you
20:29:24
Bike
i doubt sly is going for some kind of amazing transcendental experience, just better than slime
20:44:12
Xach
I remember I didn't want to try slime because i liked ILISP. But actually using it showed me how wrong I was. Even though at a high level they do the same things.
20:49:41
Xach
The slime video helped a ton in persuading me to try it. Reading static pages and screenshots, and using your imagination, is not always persuasive
21:02:34
dim
the cost of changing one's habit is very high, and slime is pretty good at what it does already
21:19:22
attila_lendvai
slime has most of the cool stuff stuffed away in contribs, e.g. the fuzzy completion
0:42:40
mfiano
The benefit of Sly is builtin mrepl, stickers, everything being a button to inspect, amoung many improvements and bug fixes.
0:44:11
mfiano
as of a few days ago, even builtin company completion with zero configuration that is much snappier than the old sly-company, or slime-company
0:45:01
mfiano
I switched from SLIME to Sly about 3 years ago and I'm still happy with that choice whenever I am reminded by using SLIME
2:00:13
kuwze
Xach: does this still work for you? http://lispblog.xach.com/post/112939066338/using-paredit-within-screen