freenode/#lisp - IRC Chatlog
Search
3:52:38
no-defun-allowed
beach: I should thank you for bringing up the mode though, now I can write `((lambda (x) x) 2) evto 2` and feel slightly less icky by using Unicode arrows.
3:54:24
no-defun-allowed
`((lambda (x) x) 2) ↦ 2` Emacs has a weird pause when I load any unicode characters though, possibly because it has to load a fallback font since CMU Typewriter Text doesn't have that character.
3:55:13
beach
I can't imagine having to type things like "first-class global environments", "Common Lisp HyperSpec", "(admittedly small) family", etc. whenever I want to mention those concepts. :)
3:58:19
beach
... and since I am apparently turning dyslexic, I would make typos trying to type those phrases each time, thereby slowing me down even more.
3:59:08
no-defun-allowed
Hm, macOS has an abbrev expander but I always thought it was annoying (since it is bound to autocorrection), which would be handy since Emacs isn't my matrix client.
4:00:44
beach
Now, what I would really like is to be able to use the same abbrev expander everywhere, in the editor, on the command line, etc.
4:01:10
no-defun-allowed
Excellent! The already half-broken input box on riot.im also breaks macOS's autocorrect too.
4:02:40
no-defun-allowed
Maybe matrix-client.el is calling again. Anyways, abbrev is very neat, thanks for mentioning it, beach.
4:47:23
pjb
beach: the problem, is to remember the abbreviations you used for those in-extenso expressions!
5:17:43
pjb
But from what I see how it behaves on smartphones, it's unsatisfactory. Perhaps with a neuralink?
5:20:44
no-defun-allowed
And a neuralink is probably another 10 years away, given the dumb hype you get from Elon, and would cost more than your computer.
7:07:05
JohnMS_WORK
I'm unable to find any examples of sharing C++ classes with ECL. Does anyone else know of any?
8:37:22
MrMc
How do I create a vector of complex numbers? I am doing the following in SBCL but get a warning (MAKE-ARRAY 1024 :ELEMENT-TYPE 'COMPLEX :INITIAL-ELEMENT (COMPLEX 0 0) :FILL-POINTER 0)
8:40:45
jackdaniel
if you put (complex 0.0 0.0) as an initial element there will be no warning too, but if you decide on complex floats then specyfing it as element type may help the compiler
8:43:17
MrMc
So my definition should be (MAKE-ARRAY 1024 :ELEMENT-TYPE '(COMPLEX FLOAT) :INITIAL-ELEMENT (COMPLEX 0.0 0.0) :FILL-POINTER 0)
8:48:56
jackdaniel
I think you gone a little overboard with this paste ,) I'm glad I could be of use
9:24:51
gjvc
* (MAKE-ARRAY 1024 :ELEMENT-TYPE '(COMPLEX FLOAT) :INITIAL-ELEMENT (COMPLEX 0.0 0.0) :FILL-POINTER 0)
9:25:53
no-defun-allowed
yeah, if the fill pointer is at 0, then it's assumed you've only populated up to 0 and the printer will print only up to there
11:37:09
MrMc
I am trying to use (bordeaux-fft:fft source) and get an error: debugger invoked on a TYPE-ERROR in thread The value #(#C(-1197.0d0 2047.0d0) .... ) is not of type (SIMPLE-ARRAY (COMPLEX DOUBLE-FLOAT) (*))
11:39:09
no-defun-allowed
You might get some slack from bordeaux-fft using bordeaux-fft:sfft, but otherwise it expects an array with :element-type (complex double-float).
11:40:36
MrMc
The array I am passing to the function is created as folows (make-array samples-to-allocate :element-type '(complex double-float) :initial-element (complex 0.0d0 0.0d0) :fill-pointer 0)
11:41:45
no-defun-allowed
Are you sure you need it? It looks you likely know how many samples you are going to transform.
12:02:12
MrMc
no-defun-allowed:removing the fill pointer did not resolve my problem but bordeaux-fft:sfft works
12:26:11
beach
jackdaniel has done some work on a CLIM-based documentation system. Either way, something like that (Concordia, was it?) would have to be defined to be used in something like CLIM, and McCLIM is quite usable now.
12:29:56
beach
an inspector (which we also have) that can do much more than the SLIME inspector, ...
12:30:03
beach
an editor (that we don't have, but it is being worked on) that can do much more than Emacs can for Common Lisp code, ...
12:30:07
beach
and a debugger (that we don't have, and for which we only have some ideas) that would be worthy of the name, unlike what we now have.
12:32:24
beach
ACTION is assuming, perhaps incorrectly, that "gd" means "good day" or something like that.
12:36:34
beach
LdBeth: There are two main ideas with Clordane. One is that I want a debugger to much more than something that lets me examine a backtrace when things go wrong. I also want to be able to set breakpoints, including in some system code. The other is that I want it to be possible for one thread to debug the code in another (or several other) threads in the same image.
12:54:39
beach
Oh, and the IDE should obviously contain ways of accessing the documentation in various ways: choosing from menus, clicking on code parts, etc.
12:58:36
beach
LdBeth: The thing about a Zmacs-like is that it is not that simple to do. For example, heisig is working on Trucler that provides incremental lexical environments. Those are needed for a sophisticated analysis of the code. And then it needs support from a compiler too, because only a compiler can determine the role of each expression in the code.
12:59:23
beach
LdBeth: And scymtym is maintaining Eclector, which is going to be used to parse the code in the buffer.
13:00:12
beach
Then that code will be "compiled" using Trucler incremental environments, either by a native compiler or by Cleavir.
13:03:06
beach
Then, errors and warnings signaled by the reader and the compiler need to be handled and presented to the user as appropriate feedback.
13:04:41
beach
LdBeth: As you can see, there are a lot of mutual dependencies here, and all the modules are being worked on. But getting them all done and working together is going to take some more time.
13:19:00
LdBeth
beach: yes. I’m planning on a tool help deriving code from specification and documents and keep docs updated with them. All these seem can be fit into my design, but I should keep up with the progress now
13:30:00
beach
scymtym: Speaking of which, did you ever get around to extracting that new function in Eclector, the one that reads either something that can be returned or something that is skipped?
13:31:56
beach
scymtym: As it turns out, in Second Climacs I couldn't find a suitable way of customizing the SICL reader to do what I need, so I copied the main reader function and modified it. That solution is clearly undesirable, so I would like to rip out that code and replace it with Eclector at some point.
13:43:02
beach
ebrasca: In American English, it means "orgasm", and in Russian it means "menopause".
13:43:50
beach
ebrasca: I'll explain the plan for Second Climacs. The plan is to use a very efficient buffer implementation, and to use the Common Lisp READ function to parse the contents of the buffer, as opposed to using regular expressions. Then the result of parsing the buffer will be handed to the compiler, for further analysis, all at typing speed.
13:46:54
jackdaniel
ecl depends on posix features. unless you put a posix system in your bios it will be hard
13:48:36
beach
ebrasca: So that the feedback will be instantaneous and without any particular keystrokes on the part of the user.
13:50:05
LdBeth
Emacs does that by saving file to disk and call the lint tool on it, which makes me worried about my disk life
13:50:11
ebrasca
beach: Can you destroy your system with it? (Like if you editing tcp of your system and you are working remotely on it.)
13:52:11
p_l
v0|d: it's possible to build ECL as EFI app, though it might take some wrangling in libs
13:52:50
beach
LdBeth: Emacs doesn't analyze Common Lisp code at typing speed. Maybe it does it with some other language.
13:53:58
p_l
the difference is that instead of crappy mishmash of CP/M emulation you're getting interesting API and modern environment
13:55:54
p_l
v0|d: the biggest issue, IMO, is intel pulling bytecode compiler behind expensive license, so bytecode use dropped heavily
13:57:27
p_l
because the only available tools stopped being available for free and now involve hefty license fee
14:00:58
p_l
the devkit remained open source (though was hard to find for some time) but the compiler ended up with high license fee
14:01:26
p_l
v0|d: significant changes between 1.10 and 2.0 which also became something actually deployed to more than just Itanium or experimental boards
14:02:26
p_l
then they put whole reference implementation (also place where some vendors put their extensions) as open source again, with all the changes since 1.10
14:05:07
p_l
v0|d: part of the complexity of UEFI API is that, like in Lisp or Smalltalk, it's very late-binding
14:07:37
p_l
you have "protocols" which have static definitions (essentially an array of function pointers), and which are identified by GUID
14:10:19
p_l
anyway, it's very nice in the sense that you can for example write a disk editor that will understand the same kind of disks that your firmware supports, without actually caring about details other than "block device"
14:11:16
v0|d
p_l: my eyes bleed when I see those new bios config screens, they are better than win3.1
14:12:07
p_l
v0|d: some people go crazy on designing them, yes. OTOH, UEFI having a gui toolkit built in means I could actually safely use serial terminal to configure everything on several machines I managed in the past
14:12:53
p_l
becuse you have a toolkit for defining menus, variables available for editing, things like that, and this is then consumed by a component which renders it on console
14:15:12
v0|d
llvm ir is so common these days, why don't uefi use it, maybe i'm wrong that llvm doesnt do real 16 code, and this sentence doesn't make sense.
14:17:14
p_l
(hell, x86 real16 code was better choice than LLVM bitcode, because you could reasonably write an emulator for that, and LLVM bitcode is extensible)
14:19:45
p_l
I switched to saying "If it's algol derived I probably can write it, and very probably read it"