freenode/lisp - IRC Chatlog
Search
0:37:25
LdBeth
Doing OOP with literature programming is way more terriable than using a lots of COME FROM
0:49:04
aeth
I fail to really see the difference between come from and goto in most languages. It looks like INTERCAL's come from uses line numbers (a feature of the language?) so "come from 230" will be a complete surprise if you're reading line 230. But most gotos use labels, so come-from in a language like CL would be the same way. So you'd (come-from label) instead of (go label) and you'd basically just trade which line has the label and which has t
0:50:35
aeth
(unless you have a confusing way of permitting multiple come-froms from the same label, but that seems adding to the basic come from)
0:56:08
oni-on-ion
aeth, can i (defun ()) something as well as execute it? like in JS we can do (function n(arg) {})(arg)
0:56:59
mange
oni-on-ion: Does n really escape that? I don't think that defines n in the wider scope.
1:01:36
aeth
oni-on-ion: defun returns the function name, so it would be just like (funcall 'foo 42)
1:02:51
aeth
oni-on-ion: every macro that has to do with iteration (e.g. DO, LOOP) in CL is typically ultimately just a macro over GO contained within the scope of a TAGBODY
1:04:40
no-defun-allowed
if wasm's supposed to compile to SSA, maybe looking at how llvm compilers handle for-loops and the like could help
1:04:58
oni-on-ion
wasm is getting a bunch more stuff i think because its not quite ready for super high level langs
1:05:43
aeth
oni-on-ion: it looks ugly, and it will warn you if you run it more than once (e.g. redefining it)
1:07:43
p_l
no-defun-allowed: interestingly enough, DEC Alpha was fastest processor on market while supporting only 32-bit-extended-to-64, 64bit ints, and few types of floats (of modern importance being only ieee 32 and 64 bit ones)
1:07:54
oni-on-ion
mhm =) not necessarily need the defun trick, but writing prototyping code, it helps to have the options. i almost needed it for how i was testing something out
1:08:54
p_l
the only issue it had was I/O due to lack of byte-sized accesses, which was worked around by intermediate chip... and which in WASM is done by exposing calls to JavaScript (which has a very limited primitive type system as well)
1:10:40
p_l
aeth: and outside of boolean, number and characters can be generalized to float64 and int32, while objects are memory accesses
1:11:19
p_l
no-defun-allowed: today's cpus have a wide variety of different types, even if ultimately they are put in rather limited forms. Legacy of CISC :)
1:14:17
p_l
a variety of ints, packed int vectors, variable-sized arrays, floats, packed float vectors, packed character vectors, encryption primitives, and include instructions which are general-purpose primitives for building things like XML processing engines
1:15:22
aeth
oni-on-ion: Supporting a console would require (1) porting SBCL, (2) replacing everything that touches SDL, (3) replacing everything that touches OpenGL. The Switch has the added challenge of not being x86-64, so it might also require improving SBCL's code generation on AMD64.
1:15:55
p_l
(SPARC is downright pedestrian, being a pretty honest RISC design with addition of supporting custom type systems that use tagged values)
1:17:45
p_l
but keep the base essentially a reiteration of MIPS because that's what the faculty taught ;)
1:19:22
p_l
which is probably why it's the only new design since 1990s to use Cray-style vector unit
1:19:32
aeth
oni-on-ion: Supporting JavaScript and probably even WASM requires writing my own Common Lisp implementation and trying to even get half the speed of what SBCL can get while working on a much higher level target.
1:19:55
aeth
It would also require replacing SDL and OpenGL (but with WebGL instead of a proprietary API). So it would probably actually be harder.
1:20:33
aeth
(Neither ParenScript nor JSCL are complete and the incomplete parts are exactly the parts you'd want for a high-performance CL application.)
1:22:30
oni-on-ion
well yes. parenscript is not meant to be a full blown CL. just a translation to JS being as close to CL as possible under that
1:22:37
aeth
oni-on-ion: But you don't even want a complete, conforming CL implementation. CLISP is one such implementation and it's still entirely unsuitable for the kind of program that my game engine is.
1:23:54
aeth
If you're writing a game, you want type declarations and other optional places where types show up to (1) be respected and (2) actually optimize what you're writing. The only place where SBCL fails here is not respecting :type in defclass at default optimization levels because SBCL primarily uses types for performance, not reliability.
1:25:54
aeth
oni-on-ion: the only things that implementations are required to respect are CHECK-TYPE and (maybe, I'm not sure) TYPEP in an ASSERT... and they don't have to optimize based on that CHECK-TYPE, either.
4:00:27
|3b|
ACTION would guess something like keeping a hash table of locations that need updated after whole thing is READ while READing it, then going back and updating once the actual value is available
4:02:01
White_Flame
if you think about it, the only way to cons up a recursive list is to mutate one of the cells to hook it back
4:05:25
|3b|
https://github.com/robert-strandh/SICL/blob/master/Code/Reader/Simple/macro-functions.lisp#L858 https://github.com/robert-strandh/SICL/blob/master/Code/Reader/Simple/read.lisp#L15 https://github.com/robert-strandh/SICL/blob/master/Code/Reader/Simple/fixup.lisp is the implementation from SICL
4:07:09
LdBeth
thanks, SICL's impl seems make more sense. CCL is restriced to use level-1 constructs.
4:07:18
|3b|
beach: in https://github.com/robert-strandh/SICL/blob/master/Code/Cleavir/Code-utilities/declarations.lisp#L74 does the "we" not include users or implementations?
4:08:54
|3b|
(users who want to introspect the env during macros etc, or cleavir-based implementations trying to use the declarations to modify codegen)
4:12:40
|3b|
beach: also, if i want to have a set of functions that are compiled specially (foreign functions with different calling convention in this case), what's the best way to specify that in cleavir? best i've come up with so far is compiler macro that turns the call into a special form that knows about the extra details
4:12:42
beach
|3b|: I think the idea is that the acceptable declaration can be customized. But Common Lisp also allows declarations that are only valid in some implementations, provided that there is a DECLARATION declaration.
4:13:46
beach
Pretty much every compilation function is a generic function, so it can be customized.
4:15:09
|3b|
possibly i just needed to cut it off higher in class hierarchy and not try to inherit from existing similar classes as much
4:15:56
|3b|
and if not clear, this is selected per function. one calling convention for FFI, and another for 'normal' functions
4:16:20
|3b|
the FFI calls need to do compile-time dispatching on name and argument type/counts, while
4:17:37
beach
The technique is as follows. Your environment must return a different INFO class for that type of function you want. Then you need to define a method on CONVERT-CST that specializes on that class.
4:17:37
|3b|
ideally transparent to user, since the differences are all internal (compile vs runtime dispatch, and hidden arguments)
4:18:06
|3b|
ok, i probably need to upgrade my sicl then, since i think i grabbed it right before you added the CST stuff :)
4:20:01
beach
You need to return a custom INFO object from the environment, and you need to add a method on CONVERT-FORM or CONVERT-CST.
4:20:23
|3b|
i think my custom info was getting converted to a global-function-info somewhere in the middle
4:24:02
|3b|
(and stubs for whatever other methods it complained about when i tried to compile something)
4:28:24
|3b|
possibly i could just have it return a special thing instead of generating a temp and looking up the function, and the code generator for funcall could just look for that thing
4:31:00
|3b|
ACTION wants a CL-like language that generates dalvik bytecode (possibly eventually a full CL, but that is relatively low priority for now)
4:31:49
|3b|
and also learning cleavir to see how well it would apply to my existing compilers with similar goals (cl-like compiler to GLSL, cl-like compiler to spir-v, etc :)
4:34:34
|3b|
but to be minimally useful, it doesn't need to be able to do too much beyond define a subclass of a java API class with a few simple methods, so it could handle events from UI
4:35:55
|3b|
ACTION already wrote a dalvik asm/disasm and some of the file format tools last time i wanted a dalvik compiler, and just mostly finished parsing the API definitions so i should be able to define subclasses and methods, and call methods
4:40:05
beach
I think it would be great to have another client. More problems will be exposed and fixed. More contributions might happen.
4:42:16
|3b|
oni-on-ion: "full" CL as in things like multiple values, conditions, automatic bignums (and ratios + complex types), clos, etc
4:44:02
|3b|
though this one will probably be closer to CL than the glsl/spirv compiler, just due to a more general-purpose target, so might support bignums, multiple values and conditions earlier
4:46:54
|3b|
like my glsl compiler has types defconstant, which doesn't match CL... would have to do separate defconstant + declaim to get a subset
4:47:40
|3b|
aeth: make sure to specify the numeric types properly (or implement full CL numeric tower) :p
4:48:01
|3b|
i guess you could just say a conforming program can't have numeric overflow in your subset
4:49:37
aeth
|3b|: typed defconstant seems pretty easy to resolve: just rename it and make it macroexpand-1 into defconstant + declaim
4:53:25
|3b|
not really something that needs resolved, just an example of how i don't try to make a 100% subset :)
4:54:42
|3b|
and to be a subset, i think that macro would need to be in the user code rather than the implementation code
5:02:01
|3b|
aeth: "any valid program in that language has equivalent semantics and will run directly (with no extralingual pre-processing, and no special compatibility packages) in any conforming implementation of the full language"
5:06:05
|3b|
ACTION supposes i could define it as requiring 'conforming programs' to also be 'conforming CL programs with same semantics', and just anything that uses the stuff that differs is non-conforming :p
5:07:10
|3b|
though 'conforming programs' in that case would be prtty small set, you could do simple math on floats, not sure how much else :p
5:08:19
aeth
I don't think it's useful to write conforming CL on the GPU, anyway. The semantics are too different.
5:09:17
aeth
I would actually intentionally name certain things differently (e.g. a different name for defun) so people don't confuse the two
5:16:28
aeth
oni-on-ion: stuff like that seems like it would be more useful as a CL library on top of a distinct GPU shader language rather than as a feature of a GPU CL
5:16:46
beach
|3b|: I am sorry that I am not extremely helpful right now. Monday mornings are chaotic here under normal circumstances. And now we have house guests as well, so I am even busier than usual.
5:17:07
aeth
oni-on-ion: the latter couldn't be 100% GPU so now you'd have a very unpredictable program where you're always asking: "Is this going to be on the CPU or the GPU?"
5:20:18
|3b|
oni-on-ion: for the specific case of glsl, the execution model is different enough from CL that i wouldn't want much more than i have (something that looks like CL but focused on that specific usage style
5:21:06
|3b|
for general GPGPU, you would probably still at least want a specialized library that generated GPU code rather than trying to translate arbitrary CL code
5:21:30
aeth
oni-on-ion: I mean this. If MAP could be single-threaded, multi-threaded, or on the GPU depending on various characteristics (like the input, which function is being used, whether or not the function is pure, etc.) then I wouldn't know what's going on at all.
5:23:26
|3b|
also moderately expensive to send things to/from GPU, so ideally you'd decide in advance that you were doing a bunch of GPU work with particular data
5:23:29
aeth
(Well, GPU-MAP would be fairly tricky, but I'd rather have it as a library than as part of the language as part of MAP.)
5:24:59
|3b|
so something like "add 10 million floats to these other 10 million floats" is fast on GPU, but if you add "copy these 20 million floats to gpu" and "copy these 20 million floats from gpu", it would have been faster to just add them on cpu
5:30:36
aeth
|3b|: I don't know. Is it possible to extend the type of a function to do things like mark functions as pure? (Or do some other declare of pure.)
5:31:44
aeth
Then a function defined in the same file or defined locally (as a lambda or with flet or with labels) or defined with sb-ext:*derive-function-types* set to T (or equivalents in other implementations if they exist, possibly CMUCL has one) could have at least more guarantees about its behavior
5:32:48
jackdaniel
ecl has "pure" proclamations (it has also "side-effect free" proclamataion, what is slightly else)
5:33:30
aeth
Would be nice to have a portability library here and to fill in the gaps where they exist (at least supporting SBCL, CCL, and ECL)
5:33:32
|3b|
(probably most compilers that want to optimize at all, so you can decide if you can completely skip calls if result isn't used, or rearrange them, or whatever)
5:34:43
jackdaniel
https://gitlab.com/embeddable-common-lisp/ecl/blob/develop/src/cmp/proclamations.lsp ←
5:34:54
aeth
|3b|: hence my qualifications of sb-ext:*derive-function-types* or defined locally to the function or defined in the same file (or compilation-unit) or defined in the locked CL package
5:35:38
aeth
Would be nice if every implementation had something like sb-ext:*derive-function-types* so you could just turn on the super optimizations super type derivations super static checking when you're done developing
5:36:17
|3b|
yeah, that's another reason for not doing full CL for dalvik to start with, easier to get small binaries :)
5:37:15
aeth
(The alternative is to put everything in one file but that breaks people's assumptions with using functions in macros because they don't put eval-when around literally everything)
5:37:47
aeth
(Also it's a bit surprising that C-c C-c could break your program because the compiler assumes C-c C-k)
5:46:56
no-defun-allowed
do you think anyone would complain if i added that to cl-vep's package.lisp?
5:52:11
aeth
no-defun-allowed: It's possible there's a way for you to set it to T, have ASDF compile your files, and then restore it to the original value. I don't know ASDF that well.
5:53:55
aeth
(There are probably some other things that are useful for final builds of a program, in various implementations)
5:56:04
no-defun-allowed
didn't seem to do much, probably since i've annotated functions myself to hell
7:19:23
isoraqathedh
You get exactly 1 argument, it must be package qualified (unless it's in cl-user, but you don't put things there anyway).
7:20:43
isoraqathedh
Wasn't there someone who wrote a replacement package for format? If I remember right there was an attempt but the format string format is used in multiple places it ended up going nowhere.
7:21:31
|3b|
it passes stream, argument to print, flags for : and @ modifiers, and any prefix arguments from format string
7:27:01
trittweiler
It's not so bad. I have a define-format-function which puts the symbols into an FMT package, so you use ~/FMT:IPV4/ for example
7:41:12
LdBeth
or backward compatibility, since the original XP used a read macro to compile format spec
7:49:52
|3b|
beach: i think my problem when i originally tried to make my own function info type is that i need a method on cleavir-env::make-info (which isn't exported) for it. otherwise it gets copied to a new global-function-info if i subclass that
8:22:13
no-defun-allowed
the blur at (x, y) is pretty much the blur at (x-1, y) minus everything at the very left column
8:22:17
beach
|3b|: I am not surprised that there are things that ought to be exported, but arten't.
8:23:02
|3b|
beach: yeah, that would require me to know what i'm doing first though, so might take a bit :)
8:23:40
|3b|
ACTION is starting to think i should just treat them as special forms instead (at the ast/IR level, not language level) :p
8:26:11
beach
Once the AST is generated, it will be a "call" AST, so you would have to do some searching and transformation of the AST I would think.
8:26:33
no-defun-allowed
right now the complexity is around O(ns), where n is pixel count and s is blur size
8:27:05
|3b|
for one thing, make-info passes special-operator-info through unmodified, so saves me a method :)
8:27:48
|3b|
but also when i did write the method, seems like most of the things it changes on global-function-info don't really apply to the ffi calls at this point anyway
8:28:33
|3b|
they are always open coded, so inline isn't really applicable, not sure dynamic extent applies, etc
8:35:39
no-defun-allowed
i have an idea for speeding up box blur which requires a diagram, can i link one here please?
8:40:39
no-defun-allowed
ACTION uploaded an image: boxblurspeedup.png (7KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/AcxdHTfXSIajKpCqLFGkdRgq >
8:40:43
no-defun-allowed
i didn't make them using a literate DSL that compiles to UML and LaTeX though so it doesn't look very good though
8:44:03
russellw
(format t "~a~36T~a~%" s) is wrapping at 80 columns. How can I get it to not do that?
11:23:29
no-defun-allowed
Implementing fast box blur can happen some other time, I've got other things to do.
11:23:30
no-defun-allowed
Right now my "feedback" value overflows so I think balancing increments (+right) and decrements (-left) isn't working.
11:30:07
no-defun-allowed
The optimal approach as far as I know is to start at the left with all pixels considered, then move right subtracting leftmost pixels and adding rightmost pixels.
11:31:06
Shinmera
no-defun-allowed: a box blur is a linearly separable convolution kernel, so you can do a horizontal and then a vertical pass. Then for dealing with edge conditions, pad your image on each side by the blur size so you don't need to check for overruns aside from the standard image bounds.
11:31:12
no-defun-allowed
The reason I think it's overflowing is because my edge logic isn't working correctly. It's literally an edge case.
11:31:36
no-defun-allowed
<no-defun-allowed "I uploaded a diagram of this ear"> Shinmera: I have written a box blur to that method but it's very slow
11:33:51
no-defun-allowed
My method doesn't require extension though, it looks at the range [max(left, 0), min(right, width-1)] and uses that size to divide.
11:37:19
no-defun-allowed
I only used that method horizontally and it's gone from 1.5 to 1.0 seconds.
11:37:49
no-defun-allowed
(now it errors with a description of where the overflow happened for testing so no, not really :)