freenode/#lisp - IRC Chatlog
Search
9:52:39
Duuqnd
beach: "freestanding code" means code that does not rely on an already established environment.
9:54:15
jackdaniel
i.e linux kernel also relies on its own estabilished environment to function correctly
9:54:45
Duuqnd
beach: I'm not sure how Mezzano works, but I think it includes a compiler that can do freestanding code.
9:55:16
beach
Duuqnd: That curious, since you just said you don't know of any system that compiles to freestanding code.
9:55:43
Duuqnd
beach: Not any standalone system. And they probably exist, I just haven't heard of them.
9:56:54
beach
Duuqnd: Either you have heard of Mezzano or you have not. You can't have it both ways.
9:56:55
jackdaniel
the facts are: there are examples of CL running on bare metal (Mezzano and Movitz as beach mentioned); there were full featured operating systems written in Lisp (on specialized hardwer, so called lisp machines)
10:00:43
Duuqnd
How about I rephrase what I said before. Mezzano includes a CL implementation, but Mezzano itself it more than that.
10:01:10
jackdaniel
if what you say is: Common Lisp standard does not specify drivers and operating system then you are correct
10:01:11
phoe
well, yes, SBCL doesn't include code for dealing with hardware or graphics or its own thread scheduler
10:03:34
jackdaniel
ACTION is tempted to throw in a statement like "but lisp is interpreted" and watch the world burn ;-) see you later
10:08:44
no-defun-allowed
But my 2¢ is that code generated by Mezzano (and I do think Movitz interpreted any functions defined in the OS) isn't freestanding, but the runtime which it utilises works directly with hardware, rather than calling into some other kernel or libc or anything like that.
10:10:25
no-defun-allowed
Yeah, there's a very large list of options you have to give to GCC to create "freestanding" code, and you probably want to set up your own cross-compiler to generate proper freestanding code.
10:11:49
no-defun-allowed
Then I would suggest that CL is more meaningless to compile freestanding than C, but all of the C specific uses of C that you C in kernels are undefined behaviour that the kernel writer likes.
10:12:00
beach
It appears that we do not have an agreed-upon definition of "freestanding", so discussing whether some compiler generates such code is not going to lead anywhere until such a definition is established.
10:13:12
Duuqnd
beach: I agree. It's hard to discuss things that nobody can agree on the definition of.
10:13:44
phoe
beach: it seems that it means that freestanding code cannot depend on anything in the OS because there is no OS to depend on - so you cannot call into libc or make syscalls and so on.
10:15:07
beach
phoe: So then, the Mezzano system is freestanding because it *is* the OS, but the Mezzano compiler does not generate freestanding code, because it relies on the Mezzano operating system for its execution.
10:15:14
phoe
gcc solves this by bundling/statically linking libc into the generated executables - in theory, so could a Lisp implementation, except it would need to e.g. use BIOS/EFI calls to write/read from standard input and storage
10:26:53
easye
phoe: Don't forget to time your return to the surface. Don't want to get the Bends from going that deep...
10:39:47
no-defun-allowed
Universal Greeting Time: http://www.total-knowledge.com/~ilya/mips/ugt.html
10:39:59
no-defun-allowed
"It states that it is always morning when person comes into a channel, and it is always late night when person leaves. Local time of any member of channel is irrelevant. Resistance is futile. Your ass will be laminated."
11:16:20
phoe
CLHS ~F says: If it is impossible to print the value in the required format in a field of width w, then one of two actions is taken. (...) If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed.
11:22:25
jackdaniel
otherwise it msut be printed, because 14. is not a float, minimal number of characters is four not 3 (in that case)
11:35:12
phoe
if the float doesn't fit in the required width and no overflow character is provided, then we print everything
11:35:18
phoe
CLHS ~F says: If it is impossible to print the value in the required format in a field of width w, then one of two actions is taken. (...) If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed.
13:12:11
ck_
sigh, what are you doing, phoe? First you spoil the integers with the (loop .. finally) bug. Now this. What are we supposed to retreat to? Character-based programming?
13:13:40
phoe
if it didn't exist, then I wouldn't have got the idea of fixing CCL up to pass more of these
13:17:05
phoe
corporate level would be to blame X3J13 for standardizing the behaviour that we are now forced to comply with in order to pass ANSI-TEST
13:20:07
phoe
at a startup level, responsibility is individual, so blaming individuals is permitted; at a corporate level, responsibility belongs to groups of people, and so we must grab larger cannons - preferably these who lay the closest to the corporate legal team.
14:34:04
beach
I am reading this page: metamodular.com/CLOS-MOP/instance-structure-protocol.html and I have a question...
14:34:41
beach
Does this page try to tell me that the location of the first slot is 0, or is it giving me the option to start at any other positive integer?
14:36:12
beach
"Locations are non-negative integers. For a given class, the locations increase consecutively, in the order that the directly accessible slots appear in the list of effective slots."
14:36:29
pjb
beach: I thought the MOP allowed you to implement objects where the storage of the slots wasn't even in-line!
14:38:09
pjb
beach: this page only says that location>=0 and that for all slots in the effective slot list, location[i+1]=1+location[i]
14:38:44
beach
Yes, but we also know that the AMOP is not a fantastic specification, so I would like to know whether they just missed that part.
14:40:47
pjb
beach: perhaps they meant to start counting from 0. But in presence of superclasses, one could assume that lower slot numbers refer to the slots of the superclass.
14:41:30
pjb
beach: but the important point is that those "location" indices are purely an API convention. It doesn't mean the slots are stored at corresponding memory location, or in the memory at all.
14:43:20
Bike
technicaly i guess they could be stored in an out of line vector or something. like you have a hash table from objects to storage vectors? that would be a ridiculous implementation, of course
14:43:47
Bike
i don't think there's much else in mop that relies on any properties of the instance slot locations, though
14:44:00
Bike
there's slot-definition-location, and (funcallable-)standard-instance-access, and I think that's it?
14:44:18
pjb
beach: also note that this concerns only "directly accessible slots" which are :allocation :instance and :type t <<< slots of other types could be allocated elsewhere and otherwise.
14:45:37
Bike
the only reason for starting at zero and improving consecutively that i can think of is making it possible to copy an object by iterating from 0 to the effective slot count, and using (funcallable-)standard-instance-access
14:45:52
Bike
but that doesn't seem like something library code should be doing anyway, in my opinion
15:00:27
phoe
CLHS, ~F: If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed.
15:01:07
phoe
What does "the scaled value" mean? If we want to print 1234.1234 in a field of length 3, do we print 1234.1 since that is the minimum, or 1234.1234 since that is literally the value?
15:02:56
phoe
Because it seems that neither SBCL or CCL complies here, as there are float-formatting ANSI-TESTs that both fail.
15:05:05
phoe
My question is whether the spec means that we should print the scaled value - in that case, 1234.1234
15:05:29
phoe
this might lead to a case when we print 1234.1234 for fields with width 5 but print 1234.1 for fields with width 6
15:06:58
pjb
the question is whether the standard specifies w as a width as in number of characters printed, or as a significant digits+dot displayed?
15:07:44
pjb
because once you admit that you will use as many character as you need to print the number (ie. more than w), why should the number still be rounded to w (-1) significant digits?
15:08:51
pjb
The standard is contradictory: It contains both: "Exactly w characters will be output." and "If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed."
15:08:58
phoe
> If it is impossible to print the value in the required format in a field of width w, then one of two actions is taken. If the parameter overflowchar is supplied, then w copies of that parameter are printed instead of the scaled value of arg. If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed.
15:09:12
phoe
"If it is impossible to print the value in the required format in a field of width w..."
15:09:45
phoe
> If it is impossible to print the value in the required format in a field of width w, then one of two actions is taken. If the parameter overflowchar is supplied, then w copies of that parameter are printed instead of the scaled value of arg. If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed.
15:09:55
pjb
(format nil "~3F" 1.234567e30) #| --> "1200000000000000000000000000000." |# more or less as specified.
15:10:01
phoe
> If the overflowchar parameter is omitted, then the scaled value is printed using more than w characters, as many more as may be needed.
15:10:16
phoe
if w is too small, then "the scaled value is printed using more than w characters, as many more as may be needed."
15:11:01
phoe
if w is too small and overflowchar is nil, then we print using as many characters as we need.
15:14:44
pjb
The problem is that rounding is specified only in the presence of d, but here, we have some rounding done also just for w.
15:15:28
phoe
pjb: there is no rounding done in case of digits before the decimal point, and CCL is wrong.
15:45:53
beach
phoe: This is silly. We should have an external and implementation-independent library for FORMAT.
15:50:45
phoe
beach: obviously we should, but I do not suspect that I can convince the implementors to use "the one #'FORMAT to rule them all"
15:52:23
phoe
as much as I'd like it to happen, it would be a pretty huge burden to maintain a loadable FORMAT module that suits all implementations
15:53:18
phoe
and an even even EVEN larger one to actually construct a library that has all the #+sbcl or #+ccl or #+ecl or #+sicl or #+whatevercl things
15:53:38
phoe
there's a lot of implementation-specific declarations in the FORMAT implementations that I've seen so far
15:54:33
phoe
I cannot answer that one - I'm not fluent enough in the internals of all the implementations
15:55:27
phoe
then also comes the bootstrapping question of when the theoretically-loadable FORMAT is needed inside the implementation's build process
15:56:04
beach
I have been giving that kind of stuff some thought lately, not for FORMAT but for READ.
15:56:25
phoe
the best system of pluggable modules that we got for Common Lisp implementations is ASDF - that itself depends on Common Lisp
15:56:49
phoe
but using ASDF to swap our components of CL itself runs into the same sort of metastability problems
15:57:11
phoe
unless we're willing to have a "secondary" CL running on top of the base one, and ASDF depending on the base one
15:57:43
phoe
but that in turn generates a clusterfuck of issues and dependencies that are not easily solvable without first-class environments
15:57:44
beach
phoe: I have been thinking that for an implementation that is written in C or C++, a READ is needed to read the code, but that READ can be fairly primitive, because code does not contain all the variations that READ allows for.
15:57:49
pfdietz
If you want to extend FORMAT, you can do it that way. Perhaps I'm not understanding the conversation.
15:58:15
phoe
pfdietz: the question is about having a FORMAT/READ/whatever implementation that you can swap out for an external one.
15:58:41
beach
phoe: Similarly, if FORMAT should be needed during bootstrapping, I am willing to bet that a small subset would be sufficient.
15:58:54
phoe
for some self-contained parts of the language such as FORMAT or LOOP that would be easier than for more wired ones
15:59:45
phoe
so basically we'd then create a set of DUMB-FORMAT, DUMB-READ, ..., that can be then used to bootstrap a Lisp implementation that can then bootstrap FORMAT, READ, ...
16:01:21
beach
I think that is the real problem. I think lots of code is specific for reasons of laziness on the part of the original creator.
16:02:04
beach
Or that there would ever be any other Common Lisp implementation than theirs worth considering.
16:02:05
phoe
I wouldn't attribute it to laziness if there was never a credible *need* for modularity in that matter.
16:02:58
beach
The need for modularity arises because we are currently overwhelmed by the collective maintenance burden or all the implementations.
16:03:16
phoe
I still disagree - even if there are ten implementations of a language, it might still be a novel idea that one could want to *dynamically* swap parts of the *language* around
16:03:52
pjb
Having common components wouldn't prevent implementations to try their own versions if they can justify them (eg. for performance or size).
16:04:05
phoe
FORMAT is a part of the language, and I want to swap it over from one implementation to the other
16:05:16
beach
If you are right about how specific the code is, swapping that way would be totally out of the question.
16:06:30
pjb
Well, you can always remove implementation specific code with a standardized API and replace it with implementation independent code.
16:07:13
beach
phoe: And why would it be more interesting to completely swap in a different FORMAT than to have a format implemented the way Eclector is, i.e., that there is a CLIENT argument that allows for implementation-specific variations?
16:07:37
beach
phoe: Then CCL could create an SBCL client instance and instantly have the SBCL behavior.
16:08:03
phoe
but then you would need to define a common format for the modules and a common API for utilizing, loading, unloading them and so on
16:08:16
pjb
Particularly, in the case of format, it is expected that there is a compiler-macro to deal with it, and this may be implementation dependent.
16:08:45
pjb
(ie. the implementation compiler macro could call implementation:internals-of-format instead of cl:format).
16:08:45
beach
pjb: Why would there be breaches of modularity in a freshly implemented library designed to be configurable and modular?
16:09:25
phoe
if one ensures that ASDF doesn't depend on the implementation's READ, LOOP, FORMAT et al (for instance, by bundling its own ones) then it would be able to load modules for FORMAT, LOOP, READ and such and expose them to the underlying implementation
16:09:27
pjb
beach: the breach would be in the old code, jumping into the internals of the implementation specific format.
16:09:46
phoe
but that already means that we marry ASDF close to each Lisp implementation and use it to load parts of the CL package.
16:10:26
pjb
beach: one example, with READ, is that to implement the dotted lists, you cannot use CL:READ. You need an internal function. So you cannot replace the reader macro for #\( without having access to the internals of the implementation specific reader.
16:11:58
Bike
the format compiler macro is commonly implemented using internal functions rather than formatter. beach is right that you'd just also defiend the compiler macro for your library, though.
16:12:16
pjb
beach: you may be right. It depends on the implementation. With old code (implementations tend to have old code) surprises are common.
16:13:19
beach
Obviously, if an old implementation does not want any of its code base to be altered, then it can not take advantage of any external configurable, implementation-independent, modular library to replace its own code.
16:15:25
phoe
beach: that is a function of people, time and money - I don't think maintainers have these galore
16:16:00
beach
But, I already said I was wrong. All implementations are old. None of them would want a single line of code to change. They all use internal stuff for good reasons.
16:16:47
phoe
it's more than possible that a lot of that code is just cruft and junk that's accumulated through years of modifications by multiple people
16:17:03
beach
Bike: Sorry. Discussions like this make me tired, and I realized I started it, so I wanted to say that I am not interested in continuing.
16:17:29
phoe
it would certainly be nice to modularize, document, refactor and otherwise modernize a lot of that code
16:18:27
phoe
and to make it more sanely bootstrappable - CCL can't even build itself without itself and it will need tons of unspaghetting the code to make even the CCL compiler loadable in SBCL
16:19:06
beach
rme hinted that it would be possible, but fairly complicated to remove the dependence on itself.
16:19:53
phoe
it would be more than lovely to have all of these features, since, frankly, CCL works and is free software - and that are the only two nice things about its source
16:20:26
phoe
it is a massive pile of spaghetti code called the CCL package where everything and the kitchen sink (sans LOOP and parts of the compiler) depends on itself
16:21:35
phoe
but up until some point it directly is a function of how much time people are willing and able to spare on making the source code better
16:21:46
phoe
at some point when everything is perfectly defined and modular there is little more to do
16:22:16
phoe
it is a function of how much time and energy people have to invest into CCL or any other implementation
16:22:36
beach
It is possible that overall programming style and developer experience evolves over time.
16:22:48
phoe
and a bit of anticipation how much foresight into what might be used or useful in the future
16:24:17
jackdaniel
format implementations (at least in cmucl, ecl and sbcl) grown from a fairly portable format implementation in cmucl
16:25:07
Bike
all fits in one file too, so that's nice, probably because it was a library at some point in the distant pats
16:25:31
phoe
since there were several prominent LOOP implementations that were then pulled into CL implementations
16:26:26
jackdaniel
and code changes because it has bugs. coming up with a new thing as a portable replacement will be similar with an exception, that the code will use current consensual coding style
16:26:40
phoe
well, one ambitious project would be to write a set of common CL modules - FORMAT, LOOP and so on, that are then pullable into CL implementations
16:26:55
phoe
and the ambitious part is to make it good enough for the implementors to consider and them perform an actual switch
16:27:16
jackdaniel
I'm not saying "beach's project" because at this point there are more people involved (vide eclector)
16:28:47
beach
phoe: And Xach was able to load SICL LOOP directly into SBCL with the purpose of catching LOOP forms that violate the standard.
16:28:51
jackdaniel
my point is that many parts of implementations which are currenlty dubbed "old" grown from independent portable modules (with some conditionalization)
16:28:52
phoe
the second point I've made still stands though - the implementations will need to ditch their old code and use the common one
16:29:27
beach
jackdaniel: I think that is right, and I also think it is done that way because they were not written to be configurable.
16:30:14
beach
And the reason they aren't configurable may well be that they didn't have the CLOS machinery at the time.
16:30:16
Bike
xerox loop is configurable. i don't think anyone's done anything with that besides adding sequence iteration, though
16:30:53
Bike
cmucl format is too, really, you should be able to add new characters reasonably easily, if you want
16:32:03
beach
So then I don't understand why it is done the way it is, i.e., copy code and modify it locally.
16:32:41
jackdaniel
beach: I think that there were some object oriented machinery at the time, but from performance perspective there could have been a penalty compared to ordinary functions
16:33:44
jackdaniel
and regarding copying code, well, imagine that the sacred format is maintained by someone somewhere -- that would make building lisp implementations considerably more painful: you need to download implementation and sacret modules to build common lisp
16:34:42
jackdaniel
etc, having your own copy is far more practical (at least from a local perspective)
16:35:08
Bike
with cleavir it's definitely been aided by my having commit access to sicl as well, so i can just fix bugs i find
16:35:23
phoe
Bike: so all implementors would need to have commit access to the theoretical LOOP repo
16:36:45
phoe
if the maintainers are responsible and capable and there are no interpersonal wars, then things are easy
16:37:22
jackdaniel
not really, if you have popular software and there is not enough capable developers then review is a time-consuming bottleneck
16:38:14
phoe
especially for popular software where you have more issues per day than you can easily count and read.
16:39:14
phoe
time to do exactly what I shouldn't - copy some SBCL code into CCL to fix some bugs and introduce new ones
17:48:43
scymtym
fiddlerwoaroof: erm, thanks. i didn't really expect anyone to find it. it isn't cleaned up, documented, finished or tested in the slightest
17:56:37
fiddlerwoaroof
I spend a lot of time attempting to imagine use-cases for funcallable objects, custom method combinations, custom metaclasses, etc., but I usually find it hard to come up with applications that aren't just a different way of doing something that's solved almost as well another way.
17:57:20
pjb
fiddlerwoaroof: for method combinations, just realize they are just monads. See how monads are useful in programming in general.
17:57:59
fiddlerwoaroof
perhaps, but I find that the standard method combination solves 90% of the problems I already have
17:59:13
pjb
But lisp is the language where the 90% that is easy is trivial, where the 9% that is hard in other language is easy, and where the 1% that is impossible in other languages is possible.
18:10:17
phoe
I am seeing ANSI-TEST failures because 1.0e+0 was expected but 1.0E+0 was printed and I want to see the part of the standard that defines this behaviour.
18:14:00
phoe
http://www.lispworks.com/documentation/HyperSpec/Body/02_cbb.htm mentions nothing about case.
18:14:04
phoe
http://www.lispworks.com/documentation/HyperSpec/Body/22_acac.htm mentions nothing about case either.
18:16:01
phoe
and if that is true, this implies that the ANSI-TESTs that tests exponent marker case are broken.
18:17:08
pjb
#+ccl (format nil "~E ~:* ~e /~:* ~(~E ~:* ~e~) /~:* ~:@(~E ~:* ~e~)" 3.14e15) #| --> "3.14E+15 3.14E+15 / 3.14e+15 3.14e+15 / 3.14E+15 3.14E+15" |#
18:17:29
jackdaniel
I think that you overuse word broken/borked/etc. incorrect would be more appropriate imo
18:18:07
phoe
and if that is true, this implies that the ANSI-TESTs that tests exponent marker case are incorrect
20:10:57
pfdietz
cl-json turns names into keywords, jsown leaves them as strings, but even converting them to keywords manually leaves jsown much faster.
20:23:54
puchacz
hi, to pass values of dynamic variables (these defparamter / let, I think they are called special variables) to a new thread, I first bind them to local variables in the parent thread like (let ((x1 *x1*)) etc. and then rebind to global symbols again from local variables in the child thread: (let ((*x1* x)) etc. it seems to work.
20:24:18
puchacz
can somebody confirm that it is correct please? and is it a portable Common Lisp way or SBCL specific?
20:26:34
puchacz
right, so all I need to do is to bind a list variable names to *default-special-bindings* and I am done?
20:29:15
phoe
it'll bind all the dynavars via PROGV and execute your thread code in its dynamic scope
20:32:58
puchacz
and if I just want the same name in car and in cdr of alist elements, it begs for a macro :)
20:37:40
puchacz
is there anything in the standard that (let ...) variables are visible in the child thread or it just a convention that happens to be followed in all major Lisps?
20:42:21
puchacz
jackdaniel - pass a closure from the parent thread to the child thread in a (let ...) variable and it will work, no matter what variables the closure refers to?
20:43:20
jackdaniel
puchacz: yes. i.e (let ((x 42)) (bt:make-thread (lambda () (let ((*something* x)) (call-my-body)))))
20:43:53
phoe
exactly what jackdaniel posted, if for some reason you don't want to use bt:*default-special-bindings*
20:44:36
jackdaniel
phoe: technically speaking they are not. special bindings may tap into implementation mechanism without creating a closure
20:45:36
phoe
jackdaniel: tapping into implementation details - how exactly do they pass values into thread functions then?
20:45:44
puchacz
for a while I thought you were saying I could (let ((x (lambda() (do-something)))) (bt:make-thread (lambda () (funcall x))) - pass a closure like this
20:48:45
jackdaniel
closures may be more expensive than ordinary functions and given a particular implementation of a dynamic environment it may be practical (performance wise)
20:51:50
puchacz
on another note, I rented a (virtual) 32 core server, exported image on my ubuntu there, with an intention to run some numerical computations (driven from my PC, invoked via simple http calls to the remote computer), and the whole thing managed to crash with messages like "CORRUPTION WARNING in SBCL pid 27983(tid 0x7f8ea266f700):" 2 or 3 times
20:52:43
jackdaniel
do you by chance run jsown or other library which sets safety to 0 in some functions?
20:53:32
puchacz
it is supposed to calculate a goal function for numerical minimisation, each calculation takes parameters via hunchentoot handler, splits work between many threads and then merges result, the calculation takes about 4 seconds.
20:55:26
puchacz
however it seemed as it was hunchentoot that crashed last time, previous incidents, I did not check - "Session secret is unbound. Using Lisp's RANDOM function to initialize it." and then "Memory fault at 0x7f94e68f8000 (pc=0x536bf253, fp=0x7f8ea266c158, sp=0x7f8ea266c138) tid 0x7f8ea266f700
20:56:41
phoe
you could (sb-ext:restrict-compiler-policy 'safety 3 3) and recompile all of your code to make sure it is compiled with highest safety
20:57:18
puchacz
phoe: will it work and override even if there are "optimised" functions somewhere with safety 0?
20:58:49
puchacz
okay :) the thing is that sbcl image loads libssl when hunchentoot starts - I think
21:04:08
ark
puchacz : Are you running this from a lisp image/executable? If foreign memory is still allocated when the image is created (i.e. when `save-lisp-and-die` is called) it will likely crash the image when you start up again.
21:06:21
puchacz
ark - it is possible that libssl is being loaded when hunchentoot is loaded from quicklisp, not started later. I don't know. it happened only after few thousand calls, unfortunately few times already
21:07:37
phoe
if yes, how did you deploy your binary? did you close the foreign library before freezing and reopened it after thawing?
21:08:01
puchacz
yes, I generated binary on my computer, copied sbcl over to the virtual server and used a command line like this:
21:10:02
puchacz
sbcl --dynamic-space-size 8192 --eval '(progn (eval (read-from-string "(ql:quickload :swank :verbose t)"))(eval (read-from-string "(ql:quickload :bubrary5 :verbose t)"))(eval (read-from-string "(require :bubrary5)"))(eval (read-from-string "(in-package :bubrary5)"))(eval (read-from-string "(bubrary5::deliver-for-computation)")))'
21:10:27
ark
puchacz: If it helps, I blogged a little bit about using foreing memory with lisp images (in the context of lisp game development): https://recursive.games/posts/Beware-foreign-memory-in-lisp-images.html
21:11:26
phoe
puchacz: if you wrote the code, then you should know - do you close and reopen libssl?
21:12:27
puchacz
I don't touch libssl myself, and I don't start hunchentoot in deliver-for-computation
21:13:55
puchacz
shall I have a closer look what hunchentoot is doing, I hope it is not loading libssl when I is just (require ...) it and not start?
21:16:39
phoe
this is the list of libraries that need to be closed before you dump the image and reopened after you reload it