freenode/#lisp - IRC Chatlog
Search
9:35:54
phoe
beach: as soon as I understand how does CCL's own compiler work. I think I mostly got the part that parses Lisp code into an IR that CCL calls "acode" and that then gets stuffed into a backend for a particular platform - the latter, it's magic to me.
9:36:42
phoe
PuercoPope: I see that your test failures are because of the DISPLAY variable not being set - in that case, do set it, and set it to a meaningful value that responds to an actual X server running on your VM. That is what XFVB is for.
9:36:47
beach
Maybe you should do one step at a time, and start by replacing the CCL reader by Eclector. :)
9:37:51
phoe
beach: my first step is squashing ansi-test bugs. Once that's done, I will think of that and possibly try doing it on a separate branch.
9:39:12
beach
Though, CCL is another implementation that is written mainly in Common Lisp, so it would be a better candidate for that kind of stuff than the implementations written in C or C++.
9:41:51
phoe
beach: I know you are half joking, but maybe it's possible. If anything, one could at least introduce a decent mechanism that allows one to utilize a different implementation of #'READ than the built-in one.
9:44:48
beach
phoe: Well, my goal with SICL has always been partly to cut down on the global maintenance burden for maintainers of Common Lisp implementations. But I realized from the start that these maintainers would be reluctant to ditching their code in favor of the portable one.
11:07:34
easye
I think the EQUAL correspondence will be valid for the CL:TRUENAME of the pathname, and otherwise implementation dependent.
11:09:19
phoe
I have a CCL situation where *compile-file-pathname* is bound to a logical pathname inside the file being compiled but is a physical pathname outside it.
11:09:21
easye
Ah, man. I'm speaking as an lazy implementer here. The CLHS is a maze of twisty hyperlinks for me, all alike in different ways.
11:10:06
phoe
So either the two should be able to be equal to each other, or they should be both logical or both physical.
11:10:46
easye
CL:*LOAD-TRUENAME* should be were the comparison is made. Or the CL:TRUENAME of CL:*COMPILE-FILE-PATHNAME* for that instance of a compilation phase.
11:11:23
easye
A logical pathname is sort of a predicate that you bind at runtime to work with "reified" CL:PATHNAMEs
11:18:01
phoe
I am lazy that way. I load ANSI-TEST, set up the proper default pathname defaults, (in-package :cl-test) and just evaluate the test body.
11:20:17
MichaelRaskin
The issue is slightly unclear whether it is *compile-file-pathname* that is logical pathname (seems so)
11:21:43
phoe
The value of *compile-file-pathname* must always be a pathname or nil. The value of *compile-file-truename* must always be a physical pathname or nil.
11:22:33
phoe
During a call to compile-file, *compile-file-pathname* is bound to the pathname denoted by the first argument to compile-file, merged against the defaults.
11:23:07
MichaelRaskin
And the result has the same logical-ness as *defualt-pathname-defaults*, right?
11:24:09
phoe
merge-pathnames returns a logical pathname if and only if its first argument is a logical pathname, or its first argument is a logical pathname namestring with an explicit host, or its first argument does not specify a host and the default-pathname is a logical pathname.
11:25:03
phoe
First argument is #p"foo.lsp" and therefore has no host; the default is a physical pathname.
11:26:23
phoe
merge-pathnames returns a logical pathname only in three cases, and none of the three cases happen here.
13:15:34
phoe
I see that SBCL ignores this altogether and flips the table as soon as it sees an OR type
14:14:16
galdor
is it me or UIOP:RUN-PROGRAM does not offer the possibility to specify the directory to use as current directory for the subprocess being created ?
14:33:36
loke
ebzzry: Well, Electron is never a good idea. Regardless of what language you'r eusing.
14:35:32
ebzzry
loke: I'm leaning towards the near-native approaches, wherein Lisp controls the GUI. The way I’m desinging the system is that the GUI has access to the engine.
14:36:11
ebzzry
I feel like if I go with the Electron route, I lose that. I have to create a bridge that will communicate between JS and CL, which has a performance penalty.
14:37:38
ebzzry
My mate saw the slide presentation of Fukamachi at https://www.slideshare.net/fukamachi/building-gui-app-with-electron-and-lisp and I’m having trouble making sense out of it.
14:39:40
beach
ebzzry: I strongly recommend McCLIM. The people working on it are doing a fantastic job.
14:41:16
ebzzry
Thank you very much. I want to hear the thoughts of everyone regarding that slideshow, with emphasis on slide 29.
14:42:21
dlowe
I don't have that much brain to spare, but I wasn't able to find documentation that made it clear to me.
14:42:55
pjb
phoe: to be EQUAL two objects must be of the same type. LOGICAL-PATHNAME and PHYSICAL-PATHNAME are different types!
14:43:23
beach
CLIM is different from other GUI toolkits the way Common Lisp is different from other languages.
14:44:19
beach
dlowe: I can admit that we are behind in McCLIM documentation, and that the most complete document is still the CLIM II specification.
14:47:58
pjb
phoe: you may need to define a function such as RESOLVE-TO-SAME-FILE-P While TRUENAME usually follow symbolic links, there's also the question of hard links!
14:48:57
pjb
phoe: a RESOLVE-TO-EQUAL-PHYSICAL-PATHNAME-P could be practical and sufficient to your need, but while compiling (C), I've already had problems with different paths pointing to the same sources…
14:51:28
phoe
pjb: I have seemingly avoided all of this by removing two lines from CCL::%COMPILE-FILE.
16:49:20
phoe
Is there any CL library or implementation function that will help me simplify types as much as possible? I have a compount type such as (not (or (not (cons (eql 0) (real 3d0 3d0))) (not (cons t (eql 0))))) and I would like to make it simpler to parse.
16:51:03
phoe
Yes, that's where I am looking right now. The only thing I found in CCL is something that operates on its internal ctype representation, not on CL types.
17:09:01
pfdietz46
You might want to look at Jim Newton's PhD thesis, which he defended this summer. https://www.lrde.epita.fr/wiki/Affiche-these-JN
17:28:59
pfdietz46
There are also complexities from negative zeros, which are = but not EQL to positive zeros of the same float class
17:31:49
pfdietz46
I have a random tester for subtypep that tries various combinations that should be equivalent. Does that repo have random/random-types.lsp?
17:34:55
pfdietz46
It's ok in complicated systems for subtypep to return nil, nil. Make sure it's not doing that.
17:36:37
pfdietz46
You can find random/random-types.lsp in my ansi-test repo on GitHub. Let me check if it's public.
20:38:08
jeosol
Is any one using some CL lib for literate programming. I am trying to write some documents, but capture the output of repl -- mostly formatted output, tables, etc. No lisp code
20:38:14
mooch2
um, i'm currently trying to write a multi-system emulator in common lisp, starting with the nes. is anybody interested in maybe helping me?
21:30:01
jeosol
rumbler31: I am trying to create some blog post using markdown and export everything to html. I would like to capture output of my program that's dumped to the repl. I do that manually, but wondering if there are automated techniques like using org-model + babel (not an expert in this but seen a few videos)
21:32:30
jeosol
rumbler31: not what I mean. I mean like certain outputs just go to certain sections of the markdown documents. The example I cited (some YT tutorial) captures shell or python output from code blocks or something.