freenode/#lisp - IRC Chatlog
Search
6:43:58
loke
You need to be able to put the basic configration (like, config file locations, etc...) in the image
6:44:35
loke
Third: Whatever config has been given should used when (and if) the config system is loaded
6:46:21
loke
6) Lisp-pref initialises, and uses __only_ the information in the image to load all the other config
6:48:00
loke
phoe: Sure, but you can load climaxima using asdf:load-system as well. But I that what you're getting at is that lisp-pref is available after loading climaxima, and that is a correct assessment.
6:48:37
White_Flame
in my .sbclrc, I have (defun project () (setf *load-image-interactively* #P"....") (load #P".../image-builder.lisp"))
6:48:37
loke
The core of my issue is that you need to provide basic configuration for the system before the system is available.
6:48:55
phoe
in your .sbclrc, create a new package called CLIMAXIMA/CONFIG that exports a single DEFVAR'd symbol.
6:49:33
White_Flame
but, what to load & config is in the interacticaly loaded prop file, which can also be used from teh cmdline to create an executable image
6:49:40
loke
White_Flame: OK, so you are basically using what I proposed to be option 1 above: To have magic stuff in CL-USER
6:50:20
White_Flame
when the image-builder is loaded, if the interactive var is set, it assumes it's in SLIME. Else, it builds an executable image
6:50:25
loke
White_Flame: Of course, but this is about bootstrapping the system; to be able to tell it where that prop file is
6:50:32
phoe
loke: yep. that package can then be probed by CLIMAXIMA; if it does not exist yet, it is created and initialized with default values, otherwise the config is loaded from that package.
6:50:58
loke
phoe: Right. So it all comes down to having well-known information available to lisp-pref. Now we have three options:
6:51:38
phoe
1) sounds wrong for me because we do not want to pollute CL-USER with anything; it is a package available to the user.
6:53:18
loke
(I guess I was thinking in terms of symbol plists because both Maxima and CLIM uses them so heavily)
6:53:56
loke
White_Flame: It might not be a terrible one, but where wold you put it? It needs to do the right think on all OS'es
6:54:17
loke
And if you want to make the file location configurable, you're back to the original question again when you decide how to confige it)
6:55:08
loke
I guess some servings on #+windows, etc... one could build something that puts the config file in a reasonable lcoation on most environments.
6:56:12
White_Flame
(well, I don't know if slime supports passing things to the inferior lisp. I'm assuming you're loading your project from an already running SLIME connection)
6:56:54
White_Flame
I seem to be the only one left in the universe building executable images for deployment ;)
6:57:41
White_Flame
and of course, as an application server, it wants to continue building after the image has moved to another machine, which confuses the heck out of quicklisp and such
6:58:07
loke
White_Flame: Oh, I never do that. I always build the binary on the system where it'll be running.
7:00:02
White_Flame
sbcl --script lisp/image-builder.lisp lisp/image.prop || error "LISP BUILD FAILED"
7:00:18
White_Flame
so our system is generic, same image-builder and prop file loaded from slime to set up the environment
7:01:06
White_Flame
the image.prop does things like adds asdf dirs relative to the project, loads systems, evals toplevel stuff, etc
7:03:18
White_Flame
I would still recommend that your system not pull from some generic config, but that your generic config stuff pulls in systems and configures them. That way the systems don't need to be modified to benefit from the config
7:04:11
flip214
And I'm trying to accumulate all VLIME related things - if you know of other goodies in other repositories, please tell me.
7:07:36
loke
I think I'll go for the config file approach, and store it in a logical location based on platform. I will them provide multiple ways to override the config file location, including both a commandline option and perhaps the plist
7:12:20
otwieracz
Suddenly, everything I have typed in one instance ended up being typed in *every single running instance*.
7:13:46
otwieracz
I was pretty surprised, looking into chat log with my friend „when did I typed „sudo -i” here…”… however, I apologized him, switched channels and WAT
12:57:25
phoe
But my question maybe can be better worded as, can I DECLAIM FTYPE of a generic function?
12:59:05
phoe
then I guess I have found a minor annoyance in SBCL, unless I am wrong somewhere again. https://plaster.tymoon.eu/view/784#784
13:00:54
loke
phoe: Aren't you supposed to put the ftype proclaimation before defining the function?
14:22:10
loke
beach: This is the current brain dump: https://drive.google.com/file/d/1aaVZmegLT42ur17j7Vbtdh7auco7pmYN/view?usp=sharing
14:22:37
loke
Here's the repository, but there isn't much in it: https://github.com/lokedhs/lisp-pref
14:25:07
phoe
loke: your work partially overlaps with my PROTEST way of declaring configuration categories and configuration options.
14:26:49
phoe
DEFINE-TYPE is not the best name because it directly clashes with CL:DEFTYPE. Maybe something more verbose like DEFINE-CONFIGURATION-TYPE?
14:27:32
phoe
:STRUCTURE :STRING is unclear to me. I don't yet get what it does, and also you missed a closing paren. (:
14:28:56
phoe
Using hash-tables is a better idea. Any list of non-null lists is a valid alist, and therefore you might avoid type confusion by using hashtables.
14:31:26
phoe
So it is obvious that you don't want just a mere tree of valid lists, and instead you want an actual map from keys to values.
15:21:38
comborico1611
Which word would you use to describe the difference between a Lisp REPL to that of all the other programming language REPLs? I was thinking "memory".
15:30:18
comborico1611
shka_: Hmm. There may be more than one difference then. I was thinking on the ability to load a function onto the REPL and then call it again.
15:40:54
phoe
comborico1611: integration of the REPL with the inspector, debugger, stepper and so on
15:41:09
phoe
nowadays it isn't about the REPL itself, it's about how it integrates with everything else
15:46:30
Beepy
shka_, it looks like Rove is still by Eitaro Fukamachi, so it will probably replace Prove at some point.
16:18:09
phoe
I've only started to rewrite my old code using my new version of PROTEST and I'm already uncovering things that I should have done better back in the day
16:18:32
phoe
such as discovering that I have duplicated DEFGENERICs and I should instead create a new mixin
16:47:42
phoe
on_ion: a mixin is a superclass that is meant to be "mixed in" with other superclasses.
17:22:50
phoe
In PROTEST, a category is not particularly interesting - the category only really exists to be a reference for the programmer, and for having a docstring.
17:22:59
loke
(besides, protest is definitely somehting I need. Potato has already changed test frameworks once)
17:23:11
phoe
And a configuration entry is essentially what you describe - a value, accessed by a list of keywords.
17:24:47
phoe
loke: PROTEST isn't an abstraction over different testing libraries. It still forces you to write tests in a given test library, but it provides mechanisms for generating test cases that are textual descriptions of tests, and therefore independent of given test implementations.
17:26:09
phoe
loke: a library abstracting over multiple different testing framework would be a testing framework itself. And we already have enough of these.