skapata has quit [Remote host closed the connection]
skapata has quit [Remote host closed the connection]
asdflkj has quit [Ping timeout: 260 seconds]
asdflkj has quit [Ping timeout: 260 seconds]
DHARMAKAYA has joined #lisp
DHARMAKAYA has joined #lisp
Oladon has quit [Quit: Leaving.]
Oladon has quit [Quit: Leaving.]
no-defun-allowed has joined #lisp
no-defun-allowed has joined #lisp
pranavats has quit [Ping timeout: 240 seconds]
pranavats has quit [Ping timeout: 240 seconds]
<no-defun-allowed>
What options do I have for configuring an ASDF system to load one module if some hardware feature is detected, and another if it is not?
<no-defun-allowed>
What options do I have for configuring an ASDF system to load one module if some hardware feature is detected, and another if it is not?
contrapunctus has quit [Ping timeout: 264 seconds]
contrapunctus has quit [Ping timeout: 264 seconds]
wxie has quit [Ping timeout: 245 seconds]
wxie has quit [Ping timeout: 245 seconds]
epony has quit [Ping timeout: 240 seconds]
epony has quit [Ping timeout: 240 seconds]
<no-defun-allowed>
Actually, I may use separate systems, but I see there is a (:feature feature-expression dependency-def) in the defsystem grammar.
<no-defun-allowed>
Actually, I may use separate systems, but I see there is a (:feature feature-expression dependency-def) in the defsystem grammar.
asdflkj has joined #lisp
asdflkj has joined #lisp
<fiddlerwoaroof>
no-defun-allowed: yeah, I've used that a couple times, mostly to hide code from lispworks and abcl
<fiddlerwoaroof>
no-defun-allowed: yeah, I've used that a couple times, mostly to hide code from lispworks and abcl
contrapunctus has joined #lisp
contrapunctus has joined #lisp
<no-defun-allowed>
fiddlerwoaroof: Now I realise that I would have to push a feature first, which complicates things.
<no-defun-allowed>
fiddlerwoaroof: Now I realise that I would have to push a feature first, which complicates things.
<fiddlerwoaroof>
Yeah, although you can do that with :defsystem-depends-on
<fiddlerwoaroof>
Yeah, although you can do that with :defsystem-depends-on
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #lisp
_whitelogger_ has joined #lisp
pankajsg has joined #lisp
pankajsg has joined #lisp
<saturn2>
am i allowed to pass #'call-next-method to another function, and will that function calling it have the same effect as calling it within the method body?
<saturn2>
am i allowed to pass #'call-next-method to another function, and will that function calling it have the same effect as calling it within the method body?
<no-defun-allowed>
I have done that before, and it will work as you expect.
<no-defun-allowed>
I have done that before, and it will work as you expect.
<saturn2>
cool thanks
<saturn2>
cool thanks
<beach>
saturn2: Yes, I do it in SICL.
<beach>
saturn2: Yes, I do it in SICL.
<beach>
CALL-NEXT-METHOD is basically just an FLET that wraps the body of the method.
<beach>
CALL-NEXT-METHOD is basically just an FLET that wraps the body of the method.
<fiddlerwoaroof>
Interesting, that's a sort of clever idea
<fiddlerwoaroof>
Interesting, that's a sort of clever idea
<fiddlerwoaroof>
I'm not sure what I'd use it for
<fiddlerwoaroof>
I'm not sure what I'd use it for
<fiddlerwoaroof>
I did something sort of like that once where I had an :around method spawn a thread to run the primary method in
<fiddlerwoaroof>
I did something sort of like that once where I had an :around method spawn a thread to run the primary method in
wxie has joined #lisp
wxie has joined #lisp
<beach>
For application code, there is probably not much use for it. In SICL I use it so that the method will call an ordinary function, and perhaps have that ordinary function executed by the host during bootstrapping.
<beach>
For application code, there is probably not much use for it. In SICL I use it so that the method will call an ordinary function, and perhaps have that ordinary function executed by the host during bootstrapping.
<no-defun-allowed>
The caching-mixin in the Netfarm server binds #'call-next-method to a dynamic variable, so that the Cacle cache library can use it as a source function.
<no-defun-allowed>
The caching-mixin in the Netfarm server binds #'call-next-method to a dynamic variable, so that the Cacle cache library can use it as a source function.
<saturn2>
fiddlerwoaroof: i have a generic function that sets up dynamic bindings related to an object and calls a function, but that object can contain other objects which need their own bindings
<saturn2>
fiddlerwoaroof: i have a generic function that sets up dynamic bindings related to an object and calls a function, but that object can contain other objects which need their own bindings
<fiddlerwoaroof>
It makes sense, I'm mostly commenting because I hadn't considered using c-n-m that way
<fiddlerwoaroof>
It makes sense, I'm mostly commenting because I hadn't considered using c-n-m that way
<fiddlerwoaroof>
I'm sort of curious now if any other programming language allows a method to let some other piece of code decide whether the superclass's implementation of the method will be invoked
<fiddlerwoaroof>
I'm sort of curious now if any other programming language allows a method to let some other piece of code decide whether the superclass's implementation of the method will be invoked
<beach>
Long ago, I stopped contemplating why other languages introduce all the limitations they do.
<beach>
Long ago, I stopped contemplating why other languages introduce all the limitations they do.
<beach>
Common Lisp is the only language I know where the creators seem to have deliberately pushed the frontiers as far as they could without risking the possibility that the compiler could not do its job.
<beach>
Common Lisp is the only language I know where the creators seem to have deliberately pushed the frontiers as far as they could without risking the possibility that the compiler could not do its job.
<fiddlerwoaroof>
Would storing c-n-m in a slot and calling it in an :after method be permissible for a conforming program?
<fiddlerwoaroof>
Would storing c-n-m in a slot and calling it in an :after method be permissible for a conforming program?
<fiddlerwoaroof>
Yeah, most programming languages I've come across seem to be designed to prevent programemrs from doing things: Java/Go more explicitly than most
<fiddlerwoaroof>
Yeah, most programming languages I've come across seem to be designed to prevent programemrs from doing things: Java/Go more explicitly than most
<no-defun-allowed>
I don't think call-next-method can cross method boundaries.
<no-defun-allowed>
I don't think call-next-method can cross method boundaries.
<no-defun-allowed>
"The function call-next-method [...] can only be used within the body of a method defined by a method-defining form."
<no-defun-allowed>
"The function call-next-method [...] can only be used within the body of a method defined by a method-defining form."
<beach>
fiddlerwoaroof: I can kind of understand that philosophy if the rest of the language makes it easy to make mistakes, like if the language uses manual memory management, it makes sense to try to make it hard to have memory leaks. But it is usually a better idea to remove the initial problem then.
<beach>
fiddlerwoaroof: I can kind of understand that philosophy if the rest of the language makes it easy to make mistakes, like if the language uses manual memory management, it makes sense to try to make it hard to have memory leaks. But it is usually a better idea to remove the initial problem then.
<fiddlerwoaroof>
Maybe I misunderstand the question, I thought the question was about situations where c-n-m might be called outside the dynamic-extent of a method
<fiddlerwoaroof>
Maybe I misunderstand the question, I thought the question was about situations where c-n-m might be called outside the dynamic-extent of a method
<fiddlerwoaroof>
I think I'm wrong
<fiddlerwoaroof>
I think I'm wrong
<beach>
I think by using automatic memory management and strong dynamic typing, Common Lisp has the right idea for avoiding such mistakes. So there is no reason to make it harder to use other programming techniques.
<beach>
I think by using automatic memory management and strong dynamic typing, Common Lisp has the right idea for avoiding such mistakes. So there is no reason to make it harder to use other programming techniques.
<fiddlerwoaroof>
The interesting thing is that Java and Go are both GCed langauges
<fiddlerwoaroof>
The interesting thing is that Java and Go are both GCed langauges
<beach>
Sure, it is not a sufficient condition.
<beach>
Sure, it is not a sufficient condition.
<beach>
The creators must also give some thought to this "pushing the frontiers" idea.
<beach>
The creators must also give some thought to this "pushing the frontiers" idea.
<asarch>
What can you do if two different packages have the same function name? Let's say foo:baz and bar:baz, what can you do in such cases?
<asarch>
What can you do if two different packages have the same function name? Let's say foo:baz and bar:baz, what can you do in such cases?
<mfiano>
call them by foo:baz and bar:baz?
<mfiano>
call them by foo:baz and bar:baz?
<beach>
asarch: I think you have been told in the past not to :USE arbitrary packages.
<beach>
asarch: I think you have been told in the past not to :USE arbitrary packages.
<asarch>
Note: you don't own those packages, you just (ql:quickload :foo) and (ql:quickload :bar)
<asarch>
Note: you don't own those packages, you just (ql:quickload :foo) and (ql:quickload :bar)
<beach>
asarch: Then why do you have a problem?
<beach>
asarch: Then why do you have a problem?
<mfiano>
The only package you should :USE is :COMMON-LISP, unless you know what you're doing and can deal with the consequences of breakage and the effects it has on others reading your code
<mfiano>
The only package you should :USE is :COMMON-LISP, unless you know what you're doing and can deal with the consequences of breakage and the effects it has on others reading your code
<beach>
asarch: They are in different packages, so there is no conflict.
<beach>
asarch: They are in different packages, so there is no conflict.
theothor` has joined #lisp
theothor` has joined #lisp
<asarch>
And the (use-package :foo) (use-package :bar)
<asarch>
And the (use-package :foo) (use-package :bar)
<beach>
asarch: Besides, Quickload loads systems, not packages.
<beach>
asarch: Besides, Quickload loads systems, not packages.
<mfiano>
Do not use-package
<mfiano>
Do not use-package
<beach>
asarch: DON'T USE ARBITRARY PACKAGES!
<beach>
asarch: DON'T USE ARBITRARY PACKAGES!
<beach>
:USE, I mean.
<beach>
:USE, I mean.
<beach>
asarch: I am pretty sure we have been through this issue before.
<beach>
asarch: I am pretty sure we have been through this issue before.
<mfiano>
Yes, we have.
<mfiano>
Yes, we have.
varjag has quit [Ping timeout: 256 seconds]
varjag has quit [Ping timeout: 256 seconds]
<asarch>
So, instead of just (baz) I should alwasy (foo:baz)?
<asarch>
So, instead of just (baz) I should alwasy (foo:baz)?
<beach>
Yes.
<beach>
Yes.
<asarch>
Ok
<asarch>
Ok
DHARMAKAYA has quit [Quit: Turning off a portion of this simulation.]
DHARMAKAYA has quit [Quit: Turning off a portion of this simulation.]
srandon111 has joined #lisp
srandon111 has joined #lisp
<mfiano>
Packages are good documentation. THink how hard it would be to understand a package that :USE'd 10 other packages.
<mfiano>
Packages are good documentation. THink how hard it would be to understand a package that :USE'd 10 other packages.
<fiddlerwoaroof>
Or, you can (:import #:foo #:baz) in your DEFPACKAGE and refer to bar:baz explicitly
<fiddlerwoaroof>
Or, you can (:import #:foo #:baz) in your DEFPACKAGE and refer to bar:baz explicitly
<asarch>
I just tried to split my HTML generator into small pieces but, once again, the function names...
<asarch>
I just tried to split my HTML generator into small pieces but, once again, the function names...
theothor` has quit [Ping timeout: 256 seconds]
theothor` has quit [Ping timeout: 256 seconds]
<beach>
I agree with mfiano. Understanding code without seeing from which package a symbol comes, is much harder.
<beach>
I agree with mfiano. Understanding code without seeing from which package a symbol comes, is much harder.
<beach>
But then, as we know, asarch does not seem concerned about other people understanding the code.
<beach>
But then, as we know, asarch does not seem concerned about other people understanding the code.
<mfiano>
If it's closed code, he should care about his future self, then.
<mfiano>
If it's closed code, he should care about his future self, then.
<flip214>
beach: yeah, right. phoe: also right. thanks, everybody!
<flip214>
beach: yeah, right. phoe: also right. thanks, everybody!
<asarch>
I mean, what if you just (:use :foo :bar: :spam) for your project and it turns that some other people wrote (foo:baz) and (foo:baz)?
<asarch>
I mean, what if you just (:use :foo :bar: :spam) for your project and it turns that some other people wrote (foo:baz) and (foo:baz)?
<asarch>
I mean, (foo:baz) and (bar:baz)
<asarch>
I mean, (foo:baz) and (bar:baz)
<mfiano>
:USE brings in external symbols
<mfiano>
:USE brings in external symbols
wxie has quit [Quit: wxie]
wxie has quit [Quit: wxie]
wxie has joined #lisp
wxie has joined #lisp
<mfiano>
exported*
<mfiano>
exported*
<beach>
mfiano: I totally agree. My lousy memory makes me that other person only a few days later.
<beach>
mfiano: I totally agree. My lousy memory makes me that other person only a few days later.
<beach>
asarch: I don't understand your question.
<beach>
asarch: I don't understand your question.
<mfiano>
If you are using :USE for some package FOO, and the author of FOO changes its exports, your code has potential symbol conflicts without you doing anything wrong (except the very wrong initial use of :USE)
<mfiano>
If you are using :USE for some package FOO, and the author of FOO changes its exports, your code has potential symbol conflicts without you doing anything wrong (except the very wrong initial use of :USE)
<asarch>
Yeah
<asarch>
Yeah
<asarch>
That's why always exists foo and foo2 versions of the same module
<asarch>
That's why always exists foo and foo2 versions of the same module
<mfiano>
And when I say :USE, I mean the defpackage option or its functional counterpart, use-package
<mfiano>
And when I say :USE, I mean the defpackage option or its functional counterpart, use-package
<asarch>
And actually my question was: "what if the author of the foo package exports the same function names that the author of the bar package also exports?"
<asarch>
And actually my question was: "what if the author of the foo package exports the same function names that the author of the bar package also exports?"
<beach>
asarch: No problem. They are in different packages.
<beach>
asarch: No problem. They are in different packages.
<mfiano>
Nothing bad would happen.
<mfiano>
Nothing bad would happen.
<asarch>
"What can you do in that cases?"
<asarch>
"What can you do in that cases?"
<mfiano>
The only time there is ever a conflict is when interning symbols into the same package, which is what USE and IMPORT do
<mfiano>
The only time there is ever a conflict is when interning symbols into the same package, which is what USE and IMPORT do
<fiddlerwoaroof>
asarch: if you insist on using :USE, you then have to :shadowing-import-from one of the symbols
<fiddlerwoaroof>
asarch: if you insist on using :USE, you then have to :shadowing-import-from one of the symbols
narimiran has quit [Ping timeout: 256 seconds]
narimiran has quit [Ping timeout: 256 seconds]
<fiddlerwoaroof>
To resolve the conflict
<fiddlerwoaroof>
To resolve the conflict
<beach>
asarch: The problem happens only when someone tries to :USE two such packages. So don't do that.
<beach>
asarch: The problem happens only when someone tries to :USE two such packages. So don't do that.
<fiddlerwoaroof>
But, this is basically why you don't use :USE
<fiddlerwoaroof>
But, this is basically why you don't use :USE
<asarch>
Thank you!
<asarch>
Thank you!
<asarch>
I thought I could (use-package :foo) and (use-package :bar)
<asarch>
I thought I could (use-package :foo) and (use-package :bar)
<beach>
Now you know better.
<beach>
Now you know better.
<beach>
asarch: I think it is time for you to "grow up" as a developer, and start contemplating the consequences of some of the practices that you may have taken for granted in the past.
<beach>
asarch: I think it is time for you to "grow up" as a developer, and start contemplating the consequences of some of the practices that you may have taken for granted in the past.
<asarch>
Yeah, I know
<asarch>
Yeah, I know
<asarch>
I just tear off the page of my notes where it says I can use (use-package)
<asarch>
I just tear off the page of my notes where it says I can use (use-package)
<asarch>
And writing a new one saying "Don't use (use-package)"
<asarch>
And writing a new one saying "Don't use (use-package)"
Lord_Nightmare has quit [Read error: Connection reset by peer]
Lord_Nightmare has quit [Read error: Connection reset by peer]
<Alfr>
asarch, there's also package-local-nicknames, if you're willing to depend on that extension.
<Alfr>
asarch, there's also package-local-nicknames, if you're willing to depend on that extension.
<saturn2>
if you want to avoid typing the package name over and over, you can use :import-from
<saturn2>
if you want to avoid typing the package name over and over, you can use :import-from
<beach>
asarch: If you rely on a list of "do"s and "don't"s without understanding why, you won't "grow up".
<beach>
asarch: If you rely on a list of "do"s and "don't"s without understanding why, you won't "grow up".
<asarch>
Two days ago I wrote: "Put the class into its package so you can protect its protocol from outside"
<asarch>
Two days ago I wrote: "Put the class into its package so you can protect its protocol from outside"
<asarch>
I also write the explanation
<asarch>
I also write the explanation
<beach>
That's progress.
<beach>
That's progress.
<White_Flame>
use-package can be okay if you're interactively testing what you might want to be visible, from a temporary repl usage
<White_Flame>
use-package can be okay if you're interactively testing what you might want to be visible, from a temporary repl usage
<mfiano>
Everything exists for a reason, and it has its uses, though they are rare. I would document your learning experience with reasoning, so your future self knows why, otherwise you are following these rules for no reason and won't know that the tool you need exists later when you "grow up"
<mfiano>
Everything exists for a reason, and it has its uses, though they are rare. I would document your learning experience with reasoning, so your future self knows why, otherwise you are following these rules for no reason and won't know that the tool you need exists later when you "grow up"
<asarch>
That's why I always ask "why"
<asarch>
That's why I always ask "why"
cchristiansen has quit [Remote host closed the connection]
cchristiansen has quit [Remote host closed the connection]
<White_Flame>
also remember that when it took forever on 80s hardware to rebuild the state of an image, you had to mutate your existing state, as opposed to simply editing your definitions and restarting
<White_Flame>
also remember that when it took forever on 80s hardware to rebuild the state of an image, you had to mutate your existing state, as opposed to simply editing your definitions and restarting
<asarch>
Yeah, those were the days...
<asarch>
Yeah, those were the days...
Lord_Nightmare has joined #lisp
Lord_Nightmare has joined #lisp
<White_Flame>
now with things fast, we can relegate many of those environmental mutators to the past
<White_Flame>
now with things fast, we can relegate many of those environmental mutators to the past
<mfiano>
asarch: Also, reeading your questions, I am curious if you know what a package does. Do you?
<mfiano>
asarch: Also, reeading your questions, I am curious if you know what a package does. Do you?
<asarch>
As a way to encapsulate functions?
<asarch>
As a way to encapsulate functions?
<mfiano>
No
<mfiano>
No
<mfiano>
Packages only contain symbols
<mfiano>
Packages only contain symbols
<asarch>
Also as a name space
<asarch>
Also as a name space
<asarch>
?
<asarch>
?
<mfiano>
So I was right. You seemed to be confused about "functions in packages", and "quickloading packages", both of which are impossible.
<mfiano>
So I was right. You seemed to be confused about "functions in packages", and "quickloading packages", both of which are impossible.
<asarch>
Oh :-(
<asarch>
Oh :-(
<mfiano>
The only purpose a package serves is as a container of symbol objects.
<mfiano>
The only purpose a package serves is as a container of symbol objects.
<White_Flame>
in other words, ONLY as a name space
<White_Flame>
in other words, ONLY as a name space
<mfiano>
Symbols have function cells, but they have other cells too. And functions don't even need to be associated with a symbol.
<mfiano>
Symbols have function cells, but they have other cells too. And functions don't even need to be associated with a symbol.
<saturn2>
it's annoying that other languages have standardized on "packages" to mean systems, and "modules" to mean packages
<saturn2>
it's annoying that other languages have standardized on "packages" to mean systems, and "modules" to mean packages
<White_Flame>
I think "namespace" is most appropriate if lisp packages were to be renamed
<White_Flame>
I think "namespace" is most appropriate if lisp packages were to be renamed
<White_Flame>
I know C++ uses that naming, not sure how many others do
<White_Flame>
I know C++ uses that naming, not sure how many others do
<asarch>
Common Lisp should be the first and *only* programming language to be taught
<asarch>
Common Lisp should be the first and *only* programming language to be taught
<saturn2>
amen
<saturn2>
amen
<mfiano>
If it were to be renamed, it should be called what it is most resembling of in other languages' (compilers): a symbol table
<mfiano>
If it were to be renamed, it should be called what it is most resembling of in other languages' (compilers): a symbol table
jonatack_ has quit [Quit: jonatack_]
jonatack_ has quit [Quit: jonatack_]
louis771 has joined #lisp
louis771 has joined #lisp
<asarch>
I will write a book with all my notes: "The Wrong Way to Use Common Lisp" :-P
<asarch>
I will write a book with all my notes: "The Wrong Way to Use Common Lisp" :-P
<asarch>
Or, "Common Lisp: The Wrong Way"
<asarch>
Or, "Common Lisp: The Wrong Way"
frost-lab has quit [Ping timeout: 256 seconds]
frost-lab has quit [Ping timeout: 256 seconds]
pve has joined #lisp
pve has joined #lisp
<mfiano>
The Right Way to (:USE :COMMON-LISP)
<mfiano>
The Right Way to (:USE :COMMON-LISP)
<asarch>
That would be the chapter 5
<asarch>
That would be the chapter 5
<White_Flame>
The Left Way to :COMMON-LISP :USE, Forth Edition
<White_Flame>
The Left Way to :COMMON-LISP :USE, Forth Edition
<mfiano>
Speaking of books, I believe the first recipe (IIRC) of Common Lisp Recipes is what you need to be reading, asarch
<mfiano>
Speaking of books, I believe the first recipe (IIRC) of Common Lisp Recipes is what you need to be reading, asarch
<asarch>
"Common Lisp is such a POWERFUL programming language that it even lets you to use it in the wrong way. Join me to this journey of dont's of this programming language"
<asarch>
"Common Lisp is such a POWERFUL programming language that it even lets you to use it in the wrong way. Join me to this journey of dont's of this programming language"
<mfiano>
Yes, first in that book is "Understanding the Role of Packages and the Symbol Nomenclature", for good reason
<mfiano>
Yes, first in that book is "Understanding the Role of Packages and the Symbol Nomenclature", for good reason
theothor` has joined #lisp
theothor` has joined #lisp
theothor` has quit [Remote host closed the connection]
theothor` has quit [Remote host closed the connection]
louis771 has quit [Quit: My M1 has gone to sleep. ZZZzzz…]
louis771 has quit [Quit: My M1 has gone to sleep. ZZZzzz…]
Inoperable has quit [Quit: All your buffer are belong to us!]
Inoperable has quit [Quit: All your buffer are belong to us!]
<phantomics>
Hey, a question about arrays. A while back I discovered that a multithreading function that assigns to elements of an array that are less than 8 bits wide can cause problems, since 1 byte is the smallest addressable amount of memory and if two threads try to assign to elements within the same byte one assignment will clobber the other
<phantomics>
Hey, a question about arrays. A while back I discovered that a multithreading function that assigns to elements of an array that are less than 8 bits wide can cause problems, since 1 byte is the smallest addressable amount of memory and if two threads try to assign to elements within the same byte one assignment will clobber the other
<White_Flame>
I once opened the CL package lock in SBCL so that I could redefine EQUALP. Does that count as a wrong way?
<White_Flame>
I once opened the CL package lock in SBCL so that I could redefine EQUALP. Does that count as a wrong way?
metehan has quit [Remote host closed the connection]
metehan has quit [Remote host closed the connection]
<mfiano>
White_Flame: Forth Edition :)
<mfiano>
White_Flame: Forth Edition :)
metehan has joined #lisp
metehan has joined #lisp
<asarch>
Is there "Common Lisp for Dummies"?
<asarch>
Is there "Common Lisp for Dummies"?
<phantomics>
I've remedied this for 4-bit element arrays by building a loop that assigns each pair of elements in the same thread, so that each byte is guaranteed not to be written by multiple threads
<phantomics>
I've remedied this for 4-bit element arrays by building a loop that assigns each pair of elements in the same thread, so that each byte is guaranteed not to be written by multiple threads
<mfiano>
White_Flame: It's hard to say, but in most cases a shadowing of the symbol would be "right-er"
<mfiano>
White_Flame: It's hard to say, but in most cases a shadowing of the symbol would be "right-er"
<phantomics>
However, when I try this with 2-bit integer arrays, I still see collisions. For the 2-bit arrays each multithreaded iteration handles 4 elements
<phantomics>
However, when I try this with 2-bit integer arrays, I still see collisions. For the 2-bit arrays each multithreaded iteration handles 4 elements
<mfiano>
Which implementation?
<mfiano>
Which implementation?
mgr_ has quit [Ping timeout: 240 seconds]
mgr_ has quit [Ping timeout: 240 seconds]
<stylewarning>
phantomics: honestly I think it’s best to not rely so heavily on the implementation’s internal representation and to build something yourself, if you can be hassled
<stylewarning>
phantomics: honestly I think it’s best to not rely so heavily on the implementation’s internal representation and to build something yourself, if you can be hassled
<remby>
asarch: practical common lisp looks pretty friendly
<remby>
asarch: practical common lisp looks pretty friendly
<White_Flame>
land of lisp is for noobs
<White_Flame>
land of lisp is for noobs
<phantomics>
stylewarning: like implementing arrays with a C library and then interfacing via CFFI?
<phantomics>
stylewarning: like implementing arrays with a C library and then interfacing via CFFI?
ikrabbe|2 has quit [Ping timeout: 256 seconds]
ikrabbe|2 has quit [Ping timeout: 256 seconds]
<mfiano>
SBCL has an "everything is volatile" memory model. This means with max speed (expt (aref array i) 2) is preferred over (* (aref array i) (aref array i)), if you want it to make some optimizations (and not receive compiler notes).
<mfiano>
SBCL has an "everything is volatile" memory model. This means with max speed (expt (aref array i) 2) is preferred over (* (aref array i) (aref array i)), if you want it to make some optimizations (and not receive compiler notes).
<mfiano>
It doesn't attempt to prove that 2 threads will not be making separate reads
<mfiano>
It doesn't attempt to prove that 2 threads will not be making separate reads
<White_Flame>
or (let ((x (aref ...)) (* x x))
<White_Flame>
or (let ((x (aref ...)) (* x x))
<no-defun-allowed>
Is there a point to working with less than 8-bit element types?
<no-defun-allowed>
Any loads and writes still require a lot of masking, unless you use SIMD-within-a-register head-hurting techniques.
<no-defun-allowed>
Any loads and writes still require a lot of masking, unless you use SIMD-within-a-register head-hurting techniques.
<no-defun-allowed>
Is there a point to working with less than 8-bit element types?
<no-defun-allowed>
beach: Reminds me, doing SIMD with general purpose registers is sometimes called "SIMD within a register" or SWAR.
<no-defun-allowed>
beach: Reminds me, doing SIMD with general purpose registers is sometimes called "SIMD within a register" or SWAR.
<White_Flame>
ldb and bitvectors help
<White_Flame>
ldb and bitvectors help
<beach>
no-defun-allowed: I see.
<beach>
no-defun-allowed: I see.
gaqwas has joined #lisp
gaqwas has joined #lisp
<stylewarning>
phantomics: you could allocate foreign memory (if you’re ok freeing it yourself), or you could choose a very safe data structure (like an (unsigned-byte 8) simple-array)
<stylewarning>
phantomics: you could allocate foreign memory (if you’re ok freeing it yourself), or you could choose a very safe data structure (like an (unsigned-byte 8) simple-array)
mgr_ has joined #lisp
mgr_ has joined #lisp
remby has quit [Quit: remby]
remby has quit [Quit: remby]
<phantomics>
no-defun-allowed: there are plenty of situations where binary arrays are used, also sub-8-bit ints are used in some situations
<phantomics>
no-defun-allowed: there are plenty of situations where binary arrays are used, also sub-8-bit ints are used in some situations
<stylewarning>
By “safe” I mean most compiler implementers won’t do something too goofy
<stylewarning>
By “safe” I mean most compiler implementers won’t do something too goofy
<phantomics>
I use them to do work with indexed color images with less than 256 colors
<phantomics>
I use them to do work with indexed color images with less than 256 colors
<White_Flame>
phantomics: are you ever doing non-byte-aligned multi-bit updates?
<White_Flame>
phantomics: are you ever doing non-byte-aligned multi-bit updates?
<no-defun-allowed>
phantomics: Do you do anything allowing you to not have to mask and shift around every AREF on sub-8-bit integer arrays?
<no-defun-allowed>
phantomics: Do you do anything allowing you to not have to mask and shift around every AREF on sub-8-bit integer arrays?
<phantomics>
White_Flame: not now but in the future yes
<phantomics>
White_Flame: not now but in the future yes
<White_Flame>
erm, updates that span multiple bytes
<White_Flame>
erm, updates that span multiple bytes
<White_Flame>
yeah, that would be harder. For plain bytes, CAS would be fine
<White_Flame>
yeah, that would be harder. For plain bytes, CAS would be fine
<phantomics>
no-defun-allowed: there are many operations in April where SWAR and such techniques would make sense, I haven't gotten into it yet
<phantomics>
no-defun-allowed: there are many operations in April where SWAR and such techniques would make sense, I haven't gotten into it yet
<White_Flame>
sbcl has sb-ext:atomic-update which might be even more approraite for your usage, as it takes care of the retry for you
<White_Flame>
sbcl has sb-ext:atomic-update which might be even more approraite for your usage, as it takes care of the retry for you
<no-defun-allowed>
Why even bother with a CAS if we only expect one writer to touch one element (unless that is not the case)?
<no-defun-allowed>
Why even bother with a CAS if we only expect one writer to touch one element (unless that is not the case)?
frost-lab has joined #lisp
frost-lab has joined #lisp
zaquest has quit [Quit: Leaving]
zaquest has quit [Quit: Leaving]
<White_Flame>
I'm assuming 1 thread is updating bits 0/1, and another thread is updating bits 2/3, as described
<White_Flame>
I'm assuming 1 thread is updating bits 0/1, and another thread is updating bits 2/3, as described
<stylewarning>
no-defun-allowed: the problem is that the API exposes one element as actually a segment of one element
<stylewarning>
no-defun-allowed: the problem is that the API exposes one element as actually a segment of one element
<no-defun-allowed>
It appears that would be the case, supposing that we do one operation at a time - oh, okay then.
<no-defun-allowed>
It appears that would be the case, supposing that we do one operation at a time - oh, okay then.
<phantomics>
White_Flame: that could help, but I'd prefer to be compatible across impls
<phantomics>
White_Flame: that could help, but I'd prefer to be compatible across impls
sabasedigh has joined #lisp
sabasedigh has joined #lisp
pranavats has joined #lisp
pranavats has joined #lisp
<White_Flame>
threading is always implementation-specific
<White_Flame>
threading is always implementation-specific
<White_Flame>
but there should be cas portability libs
<White_Flame>
but there should be cas portability libs
<mfiano>
White_Flame: Shinmera's atomics makes that a bit more portable
<mfiano>
White_Flame: Shinmera's atomics makes that a bit more portable
<phantomics>
It's not clear to me why collisions are happening when the system I set up ensures that each byte is only changable by a single thread
<phantomics>
It's not clear to me why collisions are happening when the system I set up ensures that each byte is only changable by a single thread
<mfiano>
ACL, clasp, and ECL seem to also have atomic-update
<mfiano>
ACL, clasp, and ECL seem to also have atomic-update
<phantomics>
i.e. no two threads will ever be trying to write the same byte
<phantomics>
i.e. no two threads will ever be trying to write the same byte
<phantomics>
And it works for 4-bit arrays, but not 2 or 1-bit
<phantomics>
And it works for 4-bit arrays, but not 2 or 1-bit
<White_Flame>
that's likely coincidental that 4-bit works
<White_Flame>
that's likely coincidental that 4-bit works
<saturn2>
probably the implementation is loading a whole machine register instead of a byte
<saturn2>
probably the implementation is loading a whole machine register instead of a byte
zaquest has joined #lisp
zaquest has joined #lisp
<phantomics>
Ok, so loading 64 bits at a time
<phantomics>
Ok, so loading 64 bits at a time
<no-defun-allowed>
But then I think having multiple threads try to CAS a place is going to be slower than using larger element types and non-synchronising writes (or SWAR of course).
<no-defun-allowed>
But then I think having multiple threads try to CAS a place is going to be slower than using larger element types and non-synchronising writes (or SWAR of course).
<White_Flame>
depends on how randomly accessed it is
<White_Flame>
depends on how randomly accessed it is
<saturn2>
i guess implementations ought to specify how you're allowed to access arrays from different threads
<saturn2>
i guess implementations ought to specify how you're allowed to access arrays from different threads
<phantomics>
SWAR would be preferable, is there a straightforward way to use it in CL? I asked about it before, someone suggested using CFFI since there's no CL-native way to address an array with varying element sizes
<phantomics>
SWAR would be preferable, is there a straightforward way to use it in CL? I asked about it before, someone suggested using CFFI since there's no CL-native way to address an array with varying element sizes
<stylewarning>
phantomics: are these SIMPLE-ARRAYs with no funny upgraded array element type?
<stylewarning>
phantomics: are these SIMPLE-ARRAYs with no funny upgraded array element type?
<White_Flame>
no-defun-allowed: if you're dealing with 2-bit entries, going full slot for each entry means 32x the cache pressure
<White_Flame>
no-defun-allowed: if you're dealing with 2-bit entries, going full slot for each entry means 32x the cache pressure
<no-defun-allowed>
Currently I have been using SB-SYS:VECTOR-SAP and SAP-REF-<bits> to get groups of elements at a time in some tests.
<no-defun-allowed>
Currently I have been using SB-SYS:VECTOR-SAP and SAP-REF-<bits> to get groups of elements at a time in some tests.
sabasedigh has quit [Changing host]
sabasedigh has joined #lisp
sabasedigh has quit [Changing host]
sabasedigh has joined #lisp
<phantomics>
Too bad it's limited to SBCL
<phantomics>
Too bad it's limited to SBCL
<stylewarning>
phantomics: have you looked at the disassembly to see why the 2 bit thing hasn’t worked?
<stylewarning>
phantomics: have you looked at the disassembly to see why the 2 bit thing hasn’t worked?
Inoperable has joined #lisp
Inoperable has joined #lisp
<no-defun-allowed>
White_Flame: Yes, but updating bytes (which FWIW is 4× the pressure) would not require synchronisation.
<no-defun-allowed>
White_Flame: Yes, but updating bytes (which FWIW is 4× the pressure) would not require synchronisation.
<White_Flame>
ah right, but still :)
<White_Flame>
ah right, but still :)
<phantomics>
stylewarning: no, don't know assembly but planning to so I can add SIMD support
<phantomics>
stylewarning: no, don't know assembly but planning to so I can add SIMD support
<saturn2>
cffi has with-pointer-to-vector-data which lets you access the contents of a lisp array as raw memory
<saturn2>
cffi has with-pointer-to-vector-data which lets you access the contents of a lisp array as raw memory
<no-defun-allowed>
Yes, if you have large enough arrays, then the space overhead begins to hurt. But, having messed around with approximately far too much concurrent stuff, CASing hurts more.
<no-defun-allowed>
Yes, if you have large enough arrays, then the space overhead begins to hurt. But, having messed around with approximately far too much concurrent stuff, CASing hurts more.
<no-defun-allowed>
Oh, hey, I think writing to an (unsigned-byte 2) array does attempt to write 32 bits at a time on SBCL.
<no-defun-allowed>
Oh, hey, I think writing to an (unsigned-byte 2) array does attempt to write 32 bits at a time on SBCL.
<stylewarning>
phantomics: anyway, maybe you ought to try making your thread stuff less granular, try 8 bytes per thread instead of 1
<stylewarning>
phantomics: anyway, maybe you ought to try making your thread stuff less granular, try 8 bytes per thread instead of 1
<White_Flame>
this is image-based stuff, so the arrays are likely large. But what's the access pattern?
<White_Flame>
this is image-based stuff, so the arrays are likely large. But what's the access pattern?
<phantomics>
I see, so the cache pressure may be causing the issue here
<phantomics>
I see, so the cache pressure may be causing the issue here
epony has quit [Quit: QUIT]
epony has quit [Quit: QUIT]
<no-defun-allowed>
MOV [RDX+1], RBX ; RBX is in fact a 64-bit register, not 32.
<no-defun-allowed>
MOV [RDX+1], RBX ; RBX is in fact a 64-bit register, not 32.
<White_Flame>
cache pressure would be purely a speed thing, not a correctness thing
<White_Flame>
cache pressure would be purely a speed thing, not a correctness thing
<stylewarning>
phantomics: maybe even 64 bytes per thread. Why not?
<stylewarning>
phantomics: maybe even 64 bytes per thread. Why not?
<phantomics>
stylewarning: I'll give it a try
<phantomics>
stylewarning: I'll give it a try
<phantomics>
In fact one of my future dev plans has been to add a "tuning" system for April to find the sweet spot for thread granularity on a given system
<phantomics>
In fact one of my future dev plans has been to add a "tuning" system for April to find the sweet spot for thread granularity on a given system
<no-defun-allowed>
no-defun-allowed's 10 second x86-64 assembler tutorial: MOV a, b sets the value of A to B, a name ending with H or L is an 8 bit register, a name ending in X is 16, a name starting with E is 32, a name starting with R is 64
<no-defun-allowed>
no-defun-allowed's 10 second x86-64 assembler tutorial: MOV a, b sets the value of A to B, a name ending with H or L is an 8 bit register, a name ending in X is 16, a name starting with E is 32, a name starting with R is 64
<stylewarning>
“512 bits ought to be enough for anybody.”
<stylewarning>
“512 bits ought to be enough for anybody.”
<saturn2>
i would expect giving each thread a whole cache line to work with would be a lot faster anyway
<saturn2>
i would expect giving each thread a whole cache line to work with would be a lot faster anyway
frost-lab48 has joined #lisp
frost-lab48 has joined #lisp
<no-defun-allowed>
(No refunds if it takes more than 10 seconds to type or parse that.)
<no-defun-allowed>
(No refunds if it takes more than 10 seconds to type or parse that.)
<phantomics>
Basically it would brute force all the different functions with different thresholds for thread granularity until it found the optimal thresholds for each function, then store that info and use it in subsequent invocations
<phantomics>
Basically it would brute force all the different functions with different thresholds for thread granularity until it found the optimal thresholds for each function, then store that info and use it in subsequent invocations
<White_Flame>
if you're walking across the whole image linearly with N threads, then split the image into N chunks first and let each rip independently
<White_Flame>
if you're walking across the whole image linearly with N threads, then split the image into N chunks first and let each rip independently
<stylewarning>
phantomics: I’ve wanted to do such a project for a quantum computer simulator
<stylewarning>
phantomics: I’ve wanted to do such a project for a quantum computer simulator
<no-defun-allowed>
But then it also appears that (unsigned-byte 4) writes write a whole 64-bit word too.
<no-defun-allowed>
But then it also appears that (unsigned-byte 4) writes write a whole 64-bit word too.
surabax has joined #lisp
surabax has joined #lisp
<stylewarning>
no-defun-allowed: that’s why I suggest 64 bytes
<stylewarning>
no-defun-allowed: that’s why I suggest 64 bytes
<no-defun-allowed>
However, (unsigned-byte 7) does 8-bit writes.
<no-defun-allowed>
However, (unsigned-byte 7) does 8-bit writes.
<stylewarning>
no-defun-allowed: who’s gonna fetch >512 bit chunks any time soon
<stylewarning>
no-defun-allowed: who’s gonna fetch >512 bit chunks any time soon
<phantomics>
no-defun-allowed: that's interesting, wonder why it uses the big register for those small elements
<phantomics>
no-defun-allowed: that's interesting, wonder why it uses the big register for those small elements
<no-defun-allowed>
Following the jokes about cooking with AVX-512, we'll have to find a 1024-bit vector processor and use April to fry an egg with that.
<no-defun-allowed>
Following the jokes about cooking with AVX-512, we'll have to find a 1024-bit vector processor and use April to fry an egg with that.
frost-lab has quit [Ping timeout: 268 seconds]
frost-lab has quit [Ping timeout: 268 seconds]
<phantomics>
stylewarning: do you mean 64 bytes or 64 bits? Loading 8 bytes at a time should fill those 64-bit words
<phantomics>
stylewarning: do you mean 64 bytes or 64 bits? Loading 8 bytes at a time should fill those 64-bit words
<no-defun-allowed>
Sadly, no one will attempt either for another 5 years or so.
<no-defun-allowed>
Sadly, no one will attempt either for another 5 years or so.
<stylewarning>
phantomics: bytes, only because some joker will fetch 512 bits through some weird AVX magic one day
<stylewarning>
phantomics: bytes, only because some joker will fetch 512 bits through some weird AVX magic one day
<no-defun-allowed>
White_Flame: Yes, but look at what is generated for (SETF AREF). SBCL writes (and also reads) whole words at a time.
<no-defun-allowed>
White_Flame: Yes, but look at what is generated for (SETF AREF). SBCL writes (and also reads) whole words at a time.
<White_Flame>
ah
<White_Flame>
ah
<White_Flame>
yep
<White_Flame>
yep
rgherdt has joined #lisp
rgherdt has joined #lisp
<White_Flame>
and (unsigned-byte 3) just does the same as 4, to avoid any cross-word fields
<White_Flame>
and (unsigned-byte 3) just does the same as 4, to avoid any cross-word fields
<phantomics>
Using SWAR techniques is appealing, but what puts me off trying no-defun's method above is portability
<phantomics>
Using SWAR techniques is appealing, but what puts me off trying no-defun's method above is portability
<phantomics>
I'll see how increasing the granularity works
<phantomics>
I'll see how increasing the granularity works
shka_ has joined #lisp
shka_ has joined #lisp
<White_Flame>
what process are you performing over the image?
<White_Flame>
what process are you performing over the image?
<phantomics>
White_Flame: are you asking me?
<phantomics>
White_Flame: are you asking me?
<White_Flame>
yes
<White_Flame>
yes
<White_Flame>
in terms of the access patterns that each operation will perform
<White_Flame>
in terms of the access patterns that each operation will perform
<phantomics>
This isn't for a particular image algo, this is for functions within the April language. They do a variety of things, like rotating arrays, sectioning arrays, splitting a higher rank array into a vector of sub-arrays, stuff like that
<phantomics>
This isn't for a particular image algo, this is for functions within the April language. They do a variety of things, like rotating arrays, sectioning arrays, splitting a higher rank array into a vector of sub-arrays, stuff like that
theothor` has joined #lisp
theothor` has joined #lisp
<White_Flame>
ah, I thought you had mentioned bitmap images above
<White_Flame>
ah, I thought you had mentioned bitmap images above
<phantomics>
Usually the access pattern has a function iterating over an input array, performing arithmetic on its row-major index and then assigning the results to an output array
<phantomics>
Usually the access pattern has a function iterating over an input array, performing arithmetic on its row-major index and then assigning the results to an output array
<phantomics>
I did, that's an example of something I've used April to do
<phantomics>
I did, that's an example of something I've used April to do
<phantomics>
The particular case I'm testing is the rotation function
<phantomics>
The particular case I'm testing is the rotation function
<no-defun-allowed>
Still, you might want to talk to heisig in the near future, because he is planning how a stable SIMD library might work.
<no-defun-allowed>
Still, you might want to talk to heisig in the near future, because he is planning how a stable SIMD library might work.
<phantomics>
I've already spoken with him, sb-simd may be a solution
<phantomics>
I've already spoken with him, sb-simd may be a solution
random-nick has joined #lisp
random-nick has joined #lisp
<White_Flame>
so, you should likely still partition the threads by the output array, as that would hope to have the least average contention
<White_Flame>
so, you should likely still partition the threads by the output array, as that would hope to have the least average contention
<White_Flame>
eg, for N threads, each gets 1/Nth of the output array to work on
<White_Flame>
eg, for N threads, each gets 1/Nth of the output array to work on
<phantomics>
That's right, threads are partitioned by the output array
<phantomics>
That's right, threads are partitioned by the output array
<White_Flame>
instead of some fixed granularity
<White_Flame>
instead of some fixed granularity
<phantomics>
But not in the way you describe, I've been partitioning it with (pdotimes) in lparallel, and for a 2-bit array, each iteration of pdotimes handles 4 elements in the array
<phantomics>
But not in the way you describe, I've been partitioning it with (pdotimes) in lparallel, and for a 2-bit array, each iteration of pdotimes handles 4 elements in the array
<White_Flame>
hmm, for the simplicity of each iteration, that's probably a pretty overhead-heavy way to go
<White_Flame>
hmm, for the simplicity of each iteration, that's probably a pretty overhead-heavy way to go
<White_Flame>
(if performance is a concern)
<White_Flame>
(if performance is a concern)
<phantomics>
If partitioning the array by thread is faster I'll try that
<phantomics>
If partitioning the array by thread is faster I'll try that
<no-defun-allowed>
"The `parts' option divides the integer range into `parts' number of parts. Default is (kernel-worker-count)." Maybe you lose out on loop unrolling, and an additional function call per iteration, but it's better than I expected.
<no-defun-allowed>
"The `parts' option divides the integer range into `parts' number of parts. Default is (kernel-worker-count)." Maybe you lose out on loop unrolling, and an additional function call per iteration, but it's better than I expected.
<White_Flame>
awareness of the size array to deal with small arrays synchronously or with fewer arrays woudl seem to make sense if it's done heavily as well
<White_Flame>
awareness of the size array to deal with small arrays synchronously or with fewer arrays woudl seem to make sense if it's done heavily as well
<White_Flame>
sorry, I'm tired:
<White_Flame>
sorry, I'm tired:
<phantomics>
White_Flame: yes, that's the tuning concept I mentioned
<phantomics>
White_Flame: yes, that's the tuning concept I mentioned
<no-defun-allowed>
That's true, yes.
<no-defun-allowed>
That's true, yes.
<White_Flame>
awareness of the size of the array, dealing with small arrays synchronously or with fewer threads, would seem to make sense if it's done heavily as well
<White_Flame>
awareness of the size of the array, dealing with small arrays synchronously or with fewer threads, would seem to make sense if it's done heavily as well
rogersm has joined #lisp
rogersm has joined #lisp
<phantomics>
I doubt it's efficient to rotate a 36-element array with 12 threads each handling 3 elements, but where the ideal threshold lies depends on the system
<phantomics>
I doubt it's efficient to rotate a 36-element array with 12 threads each handling 3 elements, but where the ideal threshold lies depends on the system
<phantomics>
So a way to benchmark that for the system and then use it for subsequent invocations would help
<phantomics>
So a way to benchmark that for the system and then use it for subsequent invocations would help
<no-defun-allowed>
Admittedly I just guess those things. I take it you tune each operation separately?
<no-defun-allowed>
Admittedly I just guess those things. I take it you tune each operation separately?
<White_Flame>
but clearly, each thread accessing a lock on the array would be the right (wrong) way to handle contention ;)
<White_Flame>
but clearly, each thread accessing a lock on the array would be the right (wrong) way to handle contention ;)
<phantomics>
I'm not tuning yet, but the idea would be to test each operation separately since they all have different overhead per iteration
<phantomics>
I'm not tuning yet, but the idea would be to test each operation separately since they all have different overhead per iteration
hjudt has joined #lisp
hjudt has joined #lisp
<no-defun-allowed>
(When I wrote a parallel merge-sort, I found (on a 6 core/12 thread machine), whichever was larger of splitting into 16 worker threads or 8192 elements per worker was approximately ideal.)
<no-defun-allowed>
(When I wrote a parallel merge-sort, I found (on a 6 core/12 thread machine), whichever was larger of splitting into 16 worker threads or 8192 elements per worker was approximately ideal.)
<phantomics>
Another interesting note: on my 3900X with 12 cores/24 threads, the largest speed increase I can get from singlethreaded is 12x on some functions, leading me to believe that CL array ops cannot be dual-threaded in a core
<phantomics>
Another interesting note: on my 3900X with 12 cores/24 threads, the largest speed increase I can get from singlethreaded is 12x on some functions, leading me to believe that CL array ops cannot be dual-threaded in a core
<no-defun-allowed>
I found some speedup with up to 12 threads on concurrent hash table tests.
<no-defun-allowed>
I found some speedup with up to 12 threads on concurrent hash table tests.
<White_Flame>
do you know that that's specific to CL array ops, and doesn't also occur in other languages?
<White_Flame>
do you know that that's specific to CL array ops, and doesn't also occur in other languages?
HDurer_ has quit [Remote host closed the connection]
HDurer_ has quit [Remote host closed the connection]
<White_Flame>
you're probably going to be hitting load/store saturation
<White_Flame>
you're probably going to be hitting load/store saturation
<phantomics>
White_Flame: nope, just citing experience with CL
<phantomics>
White_Flame: nope, just citing experience with CL
Lord_of_Life has joined #lisp
Lord_of_Life has joined #lisp
<MrtnDk[m]>
So you can code SBCL in multiple maybe threads, or what are you saying?
<MrtnDk[m]>
So you can code SBCL in multiple maybe threads, or what are you saying?
<no-defun-allowed>
If you squint hard enough at the resulting graphs, there is one line going from 1 to 6 cores, with a slope we'll call S, and then another from 6 to 12 with a slope of around 0.4 S.
<no-defun-allowed>
If you squint hard enough at the resulting graphs, there is one line going from 1 to 6 cores, with a slope we'll call S, and then another from 6 to 12 with a slope of around 0.4 S.
<no-defun-allowed>
And the same occurs with Cliff Click's table and his benchmark suite in Java.
<no-defun-allowed>
And the same occurs with Cliff Click's table and his benchmark suite in Java.
<no-defun-allowed>
phantomics: Here is a highly scientific analysis of such results. But if you use only 12 threads, do you get a 12× speedup? That is not the case here sadly.
<no-defun-allowed>
phantomics: Here is a highly scientific analysis of such results. But if you use only 12 threads, do you get a 12× speedup? That is not the case here sadly.
<beach>
MrtnDk[m]: Not sure what you are asking, but all modern Common Lisp implementations allow for an application to use multiple threads within a single Common Lisp image.
<beach>
MrtnDk[m]: Not sure what you are asking, but all modern Common Lisp implementations allow for an application to use multiple threads within a single Common Lisp image.
<no-defun-allowed>
I usually refer to the presentation (as I didn't hear of an article) <https://www.youtube.com/watch?v=WYXgtXWejRM> but it's not relevant to the performance effects of hyperthreading.
<no-defun-allowed>
I usually refer to the presentation (as I didn't hear of an article) <https://www.youtube.com/watch?v=WYXgtXWejRM> but it's not relevant to the performance effects of hyperthreading.
dhil has joined #lisp
dhil has joined #lisp
<phantomics>
Cool, hashing is another frontier of exploration for April's search and filtering functions. Dyalog uses many different hash types for elements depending on the array type
<phantomics>
Cool, hashing is another frontier of exploration for April's search and filtering functions. Dyalog uses many different hash types for elements depending on the array type
<no-defun-allowed>
phantomics: An interesting read though. The last third or so of this presentation also discusses speeding up a verification tool with lots of cores.
<no-defun-allowed>
phantomics: An interesting read though. The last third or so of this presentation also discusses speeding up a verification tool with lots of cores.
HDurer has joined #lisp
HDurer has joined #lisp
jello_pudding has quit [Ping timeout: 244 seconds]
jello_pudding has quit [Ping timeout: 244 seconds]
aindilis has quit [Read error: Connection reset by peer]
aindilis has quit [Read error: Connection reset by peer]
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger has joined #lisp
theothor` has quit [Remote host closed the connection]
hiroaki has joined #lisp
igemnace has quit [Remote host closed the connection]
sauvin_ has joined #lisp
villanella has joined #lisp
Boc has quit [Ping timeout: 264 seconds]
<sabasedigh>
ON Linux; Could one grab system info such as process id and cpu/ram usage with lisp?
<sabasedigh>
kind of system programming
<no-defun-allowed>
Almost certainly yes, but I don't know where you would grab that off the top of my head.
<epony>
sysctl
<epony>
linuzes have /proc too
<no-defun-allowed>
Yes, but where in /proc/?
<epony>
\o/ no idea
<no-defun-allowed>
Apparently /proc/self/stat has something, but I don't know the format.
OlCe has joined #lisp
<sabasedigh>
so what about file manipulation? reading/writing to a file?
<sabasedigh>
oh forget about secure connection to database.
<no-defun-allowed>
There's at least Postmodern for ORM on Postgres, and CLSQL for most SQL databases you've heard of.
<Odin->
ORMs are eil.
<Odin->
evil.
<no-defun-allowed>
I'm not making a statement on their moral standing, just that they exist.
oxum_ has quit [Remote host closed the connection]
<no-defun-allowed>
But I'd say databases are evil :)
<fiddlerwoaroof>
Postmodern isn't just an ORM
oxum has joined #lisp
<Odin->
Postmodern seems a lot more focused on the 'speak to Postgres' aspect than any other aspect.
<fiddlerwoaroof>
it includes an ORM-like functionality, but it's also just an pure-Lisp implementation of the Postgres wire protocol
<fiddlerwoaroof>
And, databases are great :)
narimiran has joined #lisp
<no-defun-allowed>
"Computing history will consider the past 50 years as a kind of Dark Ages of commercial data processing in which the religious zealots of the Church of Relationalism managed to hold back progress until a Renaissance rediscovered the Greece and Rome of pointer-based databases. Database research has produced a number of good results, but the relational database is not one of them."
<Odin->
no-defun-allowed: Well, if we get right down to it computers are evil. But I will note that I shared that view until I was forced to work with SQL directly.
<beach>
no-defun-allowed: Beautiful! Where is it from?
<fiddlerwoaroof>
Yeah, SQL isn't a great language, but the data model of relational databases is beautiful
<no-defun-allowed>
But wait, there's more! "Because "algebraic relation theory" was much more respectible than "data processing", database theoreticians could now get tenure at respectible schools whose names did not sound like the "Control Data Institute"."
cosimone has quit [Remote host closed the connection]
<beach>
Yes, the data model is "beautiful", but that doesn't make it practically useful.
<Shinmera>
Sounds like he's bitter more than he has a good point there.
<fiddlerwoaroof>
beach: I strongly disagree
<fiddlerwoaroof>
And, in general, I've found that projects at the companies I've worked for that picked non-relational databases get bogged down solving problems relational databases have solved for 30 years
<fiddlerwoaroof>
I won't say they're the best model: I really prefer datalog-style queries, but they're the best model that a working programmer can actually pick up for general-purpose data processing
oxum has quit [Remote host closed the connection]
oxum has joined #lisp
igemnace has joined #lisp
<epony>
excel for the masses
anticrisis has quit [Read error: Connection reset by peer]
cosimone has joined #lisp
louis771 has joined #lisp
johnjay has quit [Ping timeout: 265 seconds]
johnjay has joined #lisp
<varjag>
let's say i have a partial pathname from root up to a directory… how do i append the remaining subdirectory/file bit to it?
<varjag>
i have that last bit as a string
<Shinmera>
merge-pathnames
kevingal has joined #lisp
cosimone has quit [Remote host closed the connection]
bugrum has quit [Ping timeout: 240 seconds]
<varjag>
right that's what i tried first and it didn't work… but apparently i had the args in the opposite order, d'oh
<varjag>
thanks
cosimone has joined #lisp
GZJ0X__ has joined #lisp
contrapunctus has left #lisp ["Disconnected: closed"]
GZJ0X_ has quit [Remote host closed the connection]
cosimone has quit [Remote host closed the connection]
<no-defun-allowed>
Odin-: Every time someone complains, I build another computer.
phantomics has joined #lisp
johnjay has quit [Ping timeout: 240 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
Lycurgus has joined #lisp
ukari has quit [Ping timeout: 272 seconds]
johnjay has joined #lisp
vegansbane6963 has joined #lisp
wxie has quit [Ping timeout: 265 seconds]
rogersm has quit [Quit: Leaving...]
ljavorsk has quit [Remote host closed the connection]
HiRE has quit [Quit: Later]
HiRE has joined #lisp
ljavorsk has joined #lisp
GZJ0X__ has quit [Remote host closed the connection]
GZJ0X__ has joined #lisp
GZJ0X__ has quit [Remote host closed the connection]
GZJ0X__ has joined #lisp
tiwEllien has joined #lisp
sabasedigh has quit [Ping timeout: 245 seconds]
retropikzel has quit [Quit: Leaving]
galex-713 has quit [Ping timeout: 272 seconds]
asarch has quit [Quit: Leaving]
galex-713 has joined #lisp
Lycurgus has quit [Quit: Exeunt]
dddddd_ has quit [Ping timeout: 260 seconds]
jonatack has joined #lisp
theothornhill has joined #lisp
jello_pudding has joined #lisp
tmf_ has quit [Ping timeout: 246 seconds]
<contrapunctus>
no-defun-allowed: re: databases, I'm a novice programmer; the one "serious" application I've written so far stores s-expressions into a file, reads them all (thousands of them at the moment, and growing) into memory, and reads the file again (partially or wholly) if it is changed (usually by the program itself). My only concern at the moment is to prevent the waste of RAM caused this way and to read th
<contrapunctus>
e data required in a finer-grained manner. What do you suggest I use for future projects? 🤔
<no-defun-allowed>
How large is each "entry" that you are reading?
cosimone has quit [Read error: Connection reset by peer]
unimog has joined #lisp
frost-lab48 has quit [Quit: Ping timeout (120 seconds)]
cosimone has joined #lisp
Nilby has joined #lisp
<no-defun-allowed>
Ideally you should be able to perform an update without re-reading the file, but keeping everything in memory may be acceptable for your scale.
ArtOfWar has joined #lisp
<no-defun-allowed>
When I was writing an accounting program, I did an estimate that looks like this: Suppose we had a company with a hundred accountants, each of which exceptional typists who could write 200 WPM, and somehow kept it up for 10 hours a day entering in transactions. They then work 350 days a year. How many transactions could they (absolutely unrealistically) enter in a year, and how much memory would that occupy?
<no-defun-allowed>
They would "only" write 10 gigabytes or so a year, so I decided an in-memory database would be fine.
tmf has joined #lisp
sabasedigh has joined #lisp
<contrapunctus>
no-defun-allowed: Each expression is ~200 characters. It was terrible UX to re-read the file whenever something changed, but the work involved in optimizing it to support "partial reading" made me wonder if I'd have been better off with SQLite.
<no-defun-allowed>
I don't immediately see why you couldn't make the change in memory, then write out a change (or a totally new state, if incremental changes aren't worth the hassle) to disk.
<Xach>
contrapunctus: a log of updates is one handy way to avoid modifying and re-reading the file.
louis771_ has joined #lisp
<Xach>
but a "real" database is probably a better bet for many uses
<no-defun-allowed>
Yeah, a log would be a good idea, but re-reading just shouldn't be necessary at all if you have a copy in memory.
ArtOfWar has left #lisp [#lisp]
frost-lab has joined #lisp
louis771 has quit [Ping timeout: 240 seconds]
dvdmuckle has quit [Ping timeout: 264 seconds]
<contrapunctus>
no-defun-allowed: it does some expensive operations on the expressions which were read. It's possible the schema didn't help in that matter - e.g. using ISO-8601 timestamps rather than UNIX timestamps - but that was a deliberate design decision from the start. 🤔
<no-defun-allowed>
Reminds me that I am pondering how to know when to compress some logs I write to disk - now that the Netfarm semantics include "decrement a counter" as a side effect (as well as incrementing), there are now changes I can cancel out if disk space is an issue.
<contrapunctus>
MrtnDk[m]: many. Climacs, Second Climacs, Hemlock...?
<no-defun-allowed>
Mrtn Dk: You might want to avoid writing multi-line messages on IRC bridged channels, because the room sees that you mentioned a link to the content, and it won't ping beach.
<no-defun-allowed>
But beach was indeed involved in both Climacsen, and there are also Hemlock and its Portable variant.
<MrtnDk[m]>
contrapunctus: Cool!
<MrtnDk[m]>
beach Thank you for the answer.
<contrapunctus>
no-defun-allowed: oh, on the subject of Netfarm - I wonder if y'all would find this useful. Someone shared it, with the caveat that they have a lot of polishing to do before it can be used - https://github.com/danielcliffordmiller/cl-stun
* Odin-
notes that there's an interesting tendency to programming language monocultures.
<MrtnDk[m]>
*no-defun-allowed* How are the status of those? I think there was an effort to make a scheme variant of Emacs, but I think it wasn't very successful for some reason.
<no-defun-allowed>
Odin-: On the contrary to the implications of "monoculture", a programming experience with multiple languages is often the worst of all worlds involved.
<Odin->
no-defun-allowed: Yes, but that's in no small part due to the fact that many (most?) programming languages make absolutely _no_ concession to the idea that other programming languages might exist.
<MrtnDk[m]>
Odin- Are you Odin-lap? I think you implied that you were, but I'll ask to be sure.
<Odin->
MrtnDk[m]: I have used that nickname, yes.
<MrtnDk[m]>
Odin- I think I might have seen you on IRC in channel Emacs.
<no-defun-allowed>
How would an early bound language cooperate with a late bound, or anything like that, without making a system that is early bound somewhere you really don't want it to be?
<no-defun-allowed>
If that was taken into consideration, you might end up with a scenario where "all languages (actually) converge to Lisp" or whatever that was.
<MrtnDk[m]>
Odin- Are you Icelandic or, suomalainen by any chance?
<no-defun-allowed>
And a standard would likely have to cross-reference the other languages' standards.
<Odin->
no-defun-allowed: I am not suggesting that we should be aiming for some "everything just works together" scenario. More that it doesn't seem absolutely _vital_ for every tool to be implemented in every language.
<no-defun-allowed>
Every tool should be implemented in Common Lisp (or something better) still :)
<Odin->
MrtnDk[m]: Well, right now the government-run TV service where I am has a live feed of a volcano when they don't have scheduled broadcasts.
louis771_ has quit [Quit: My M1 has gone to sleep. ZZZzzz…]
<MrtnDk[m]>
Odin- You mean kinda like you can use the libc API from scheme quite effortlessly?
<Odin->
no-defun-allowed: Ideally, sure. But that's not realistically going to happen. :p
<MrtnDk[m]>
Odin- I think you're the Odin-I was thinking of then.
jprajzne has joined #lisp
<Gnuxie[m]>
Won't use the tool then
<Odin->
MrtnDk[m]: Well, for largely historical reasons _everything_ needs to be able to deal with C.
<Odin->
MrtnDk[m]: The problem is that that fact tends to support a C monoculture. :D
sabasedigh has joined #lisp
sabasedigh has quit [Changing host]
ebrasca has joined #lisp
<MrtnDk[m]>
I don't think Linux is likely to be rewritten in Common Lisp anytime soon ...
<Odin->
... mind you, I'm currently trying to learn more about Lisp by turning an interpreter written in C to a much more biased "Lisp first" way of working, so I can't claim the higher ground _that_ easily.
<Odin->
(Not Common Lisp. I'm pretty sure a proper CL wouldn't fit on _any_ AVR chip.)
<Gnuxie[m]>
'Re-written' like re writing would be an improvement js the biggest scam, like remacs, completly brain dead idea
<no-defun-allowed>
Odin-: If we don't do the impossible, we will be faced with the unthinkable.
frgo has quit [Remote host closed the connection]
frgo has joined #lisp
<Odin->
MrtnDk[m]: Linux, no. But there have been attempts at bare-x86 implementations.
sabasedigh has quit [Ping timeout: 244 seconds]
<Odin->
Gnuxie[m]: Well, it's worth remembering that GNU Emacs is itself fundamentally a rewrite.
sabasedigh has joined #lisp
<Odin->
Initially by the original author, and at a point where there wasn't an enormous existing codebase to contend with, but still...
<Odin->
no-defun-allowed: What's with the 'will be'? :)
<no-defun-allowed>
Did I forget the quote?
<Odin->
Nah, I'm just trying to imply we're already facing the unthinkable.
<Odin->
In any case.
<no-defun-allowed>
Ah, "shall be faced with". /me had one job.
<Odin->
Huh. I didn't even know that.
Spawns_Carpeting has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
<Odin->
no-defun-allowed: The thing I'm kinda complaining about is actually somewhat visible in what distinguishes Common Lisp implementations.
<no-defun-allowed>
Odin-: Sadly I can think of worse, but I suppose a lot of computing screw ups are hidden well away from mortals such as ourselves, so those are unthinkable.
<MrtnDk[m]>
Gnuxie 💜🐝 What do you mean by "remacs" and "js"?
<Odin->
If you need two-way interoperation with C, ECL is your best bet. ABCL if you have to touch Java. And Clasp is seeking to make it possible to talk to C
<Odin->
++ without a translator.
<Odin->
... bumped the enter key by accident.
Spawns_Carpeting has joined #lisp
<no-defun-allowed>
Mrtn Dk: I think Gnuxie is saying that a rewrite in itself is not interesting. The main gains are had by writing more idiomatic code, because one can write C in any language.
<splittist>
This reminds me: anyone know of a printf CL implementation?
<MrtnDk[m]>
Oh, I thought that went without saying, but I'm guessing there is another term for that, rather than "rewrite"?
<no-defun-allowed>
...which is why the reference to remacs, which rewrites the C core of GNU Emacs, but leaves it still inflexible and early bound, which is of no real benefit to the user.
<MrtnDk[m]>
splittist What's wrong with format?
<MrtnDk[m]>
*no-defun-allowed* Ah ok, never heard of remacs before.
<no-defun-allowed>
An expression-for-expression clone could be a transliteration.
<Odin->
splittist: Surely Zeta-C has one?
<no-defun-allowed>
Mrtn Dk: It is totally insignificant, other than it came up in an argument us two were in.
<Odin->
no-defun-allowed: Considering that the authors of that consider Rust to be a worthwhile improvement on C, they evidently don't have a problem with those aspects of C. :p
<MrtnDk[m]>
I can see there benefit of writing an Emacs-clone in Common Lisp though. You would be able to use threads, and that would make it run faster on raspberry pi and other multi core platforms.
<no-defun-allowed>
Yet the README says the opposite story: "Emacs is a live system, you can inspect it and update without restarting, blah blah."
<no-defun-allowed>
If they actually believed those things, they would use an interactive language.
* Nilby
thinks Emacs is a comfortable evolutionary puddle on that we should crawl out of.
<MrtnDk[m]>
Nilby Are you a vi user?
<Odin->
Nilby: What _isn't_?
<Nilby>
No. I've use emacs since it was written. It used hack Emacs professionally.
<no-defun-allowed>
C and Rust are not introspectable (as in procedural reflection), not incremental, not particuarly mutable, and do not offer ways of writing entry points that aren't "programs".
<MrtnDk[m]>
It used hack?
<Odin->
We're still using what is basically an updated telegraph code as the main representation of text.
<Nilby>
Odin-: Yes. You get it.
<MrtnDk[m]>
*no-defun-allowed* I don't think rust has anything to bring to the table, from what I hear.
<Odin->
That's leaving aside the fact that command line interfaces are still based fundamentally around the capacities of actual, _literal_ telegraph machines.
<no-defun-allowed>
Mrtn Dk: That's what Gnuxie was getting at.
<MrtnDk[m]>
Nilby What do you mean by "It used hack Emacs ..." ?
<Nilby>
It is I.
<no-defun-allowed>
You could gain some of those things from a CL port, but then you also want to reconsider any weird decisions brought on by using C.
<Odin->
MrtnDk[m]: As an implementation language for Emacs, it doesn't. My way of looking at it ... it's a good alternative choice to C++.
<MrtnDk[m]>
oh ok, that makes more sense, Nilby. You used to hack Emacs professionally. I guess you got to see some of the ugly parts of the code then?
<splittist>
Odin-: good point. I'll have a look at Vacietis.
<Nilby>
Yes. The very very ugly parts. Some of them are gone now. But the architectural problems annoy me more every day.
<MrtnDk[m]>
architectural?
<MrtnDk[m]>
Like the core design?
<Nilby>
MrtnDk[m]: Yes.
narimiran has quit [Ping timeout: 265 seconds]
<MrtnDk[m]>
I guess those problems have been solved in climacs and/or the other common Lisp versions?
<Nilby>
For example: the input loop is a single thread, so you can't switch between searching different things in different windows without trouble.
<Odin->
MrtnDk[m]: I wouldn't count on it.
<Nilby>
But like Odin mentioned, I don't think a buffer should only represented as text.
<Odin->
For instance, CL doesn't have threads.
<Odin->
The implementations do, sure. But CL doesn't.
<MrtnDk[m]>
You mean the standard, common ANSI-Lisp?
gareppa has joined #lisp
<MrtnDk[m]>
odin-
gareppa has quit [Client Quit]
<Odin->
Yes.
<Nilby>
I think every CL in actual use is significant superset of CL, such that there's nearly a new defacto standard.
<Odin->
And that means older CL emacsen are likely to have the same problem, for the same reason as GNU Emacs.
<Nilby>
Indeed. The older versions of hemlock show it's age like that.
igemnace has quit [Remote host closed the connection]
<Odin->
Nilby: All I'm saying is that architectural limitations like that don't _definitely_ go away by being written in CL, because the same historical constraints that caused the problem in GNU Emacs also applied to CL - though CL has definitely been quicker to get rid of them than Emacs has.
<White_Flame>
Nilby: alexandria and the trivial-* libraries are a certain solidification of that defacto superset
<Nilby>
I agreee. In fact it seems most Emacen in CL retain most of the architectural problems. Perhaps they mostly solve that you can redefine and extend the core more easily.
<White_Flame>
well, not even alexandria, that's just plain lisp
<Nilby>
White_Flame: Yes. And things like sockets, FFI, etc.
<White_Flame>
certainly there's a new "common" baseline of common lisp implementations to standardize
<White_Flame>
and this time they're generally much more cross-compatible
tinhatcat has joined #lisp
<Odin->
Well, this time they have a much larger common base.
villanella has quit [Remote host closed the connection]
villanella has joined #lisp
sabasedigh has quit [Ping timeout: 265 seconds]
OlCe has joined #lisp
stalwart has joined #lisp
sabasedigh has joined #lisp
Major_Biscuit has quit [Ping timeout: 272 seconds]
Major_Biscuit has joined #lisp
cosimone has joined #lisp
Ioanai7 was banned on #lisp by phoe [*!*ioana@*.154.216.137.dyn.user.ono.com]
Ioanai7 was kicked from #lisp by phoe [Ioanai7]
<phoe>
so how is everyone's lisp today
<flip214>
phoe: {curly}
aartaka_d has joined #lisp
<contrapunctus>
I'm struggling to get through the McCLIM tutorial, for some reason. Don't know why I'm having so much difficulty getting myself to focus on it.
Ioanai7 has quit [K-Lined]
aartaka has quit [Ping timeout: 265 seconds]
<Nilby>
McCLIM code has a weird soporific effect on me too.
<jackdaniel>
wait until stockholm syndrome kicks in ,-)
<contrapunctus>
But I absolutely love the presentation types idea and I have a ton of things I want to write with it :\
<Shinmera>
phoe: I'm in a flux of considering to work on a project and then deciding against it.
<jackdaniel>
contrapunctus: first define presentation types, then define command tables and at the very last define a frame and a display function
<jackdaniel>
that's (imo) the most reusable order for writing clim applications
<contrapunctus>
jackdaniel: hey ^^ thanks, I'll keep it in mind. Also, another tutorial-tweaking PR coming in soonish 🙂 (Texinfo, this time)
<jackdaniel>
great, thanks!
Lycurgus has joined #lisp
orivej has joined #lisp
tiwEllien has quit [Ping timeout: 240 seconds]
tiwEllien has joined #lisp
sabasedigh has quit [Ping timeout: 272 seconds]
jonatack has quit [Read error: Connection reset by peer]
sjl has joined #lisp
Major_Biscuit has quit [Ping timeout: 256 seconds]
bitmapper has joined #lisp
Major_Biscuit has joined #lisp
Lycurgus has quit [Quit: Exeunt]
DateMasamune2000 has joined #lisp
admich has joined #lisp
rogersm has joined #lisp
sabasedigh has joined #lisp
tiwEllien has quit [Ping timeout: 272 seconds]
tiwEllien has joined #lisp
cage_ has joined #lisp
Josh_2 has joined #lisp
Major_Biscuit has quit [Ping timeout: 265 seconds]
theothornhill has quit [Ping timeout: 265 seconds]
sabasedigh has joined #lisp
sabasedigh has quit [Changing host]
<Josh_2>
Ello ello fello lispers :P
sabasedigh has quit [Quit: ChatZilla 0.9.93.2017081717 [Basilisk 52.9.2021.03.17/20210317091816]]
flazh has quit [Quit: flazh]
waleee-cl has joined #lisp
ukari has joined #lisp
<frgo>
Hi all. I am working for the first time with CFFI's groveler. I am trying to get the package config cflags as flags set-up for the groveler. I found the groveler "syntax" pkg-config-cflags but, in contrast to e.g. "include" or "flag", CFFI's groveler doesn't seem to understand this: (pkg-config-cflags "rabbit-c" :optional t)
<frgo>
Hope one of you guys can help me out here. Any hints? Thx!!!
sabasedigh has joined #lisp
varjagg has joined #lisp
warweasle is now known as warweasle_afk
<shka_>
(ql:quickload :osicat) gives me error regarding fare-quasiquote
sabasedigh has quit [Ping timeout: 260 seconds]
<shka_>
can someone verify if this happens for them as well
<shka_>
?
varjagg has quit [Ping timeout: 245 seconds]
<Josh_2>
Works for me
<frgo>
@shka_ Works for me (SBCL 2.1.2 on macOS M1, CFFI 0.23.0)
<shka_>
ok, thanks
sabasedigh has joined #lisp
<beach>
MrtnDk[m]: Sorry, I was away. We made a certain number of mistakes in the architecture of (first) Climacs, so we are not working on it anymore. Instead we are planning Second Climacs to be a much better editor, at least for Common Lisp code. But it is going to take a while because I am busy with SICL.
<MrtnDk[m]>
SICL?
<beach>
MrtnDk[m]: Also, I think people forgot to point out to you that Unix is a disaster that was already worse then its predecessors at the time, so there would be no point in rewriting it in Common Lisp. Instead, we have a design for a pure Lisp operating system called CLOSOS: http://metamodular.com/closos.pdf
<beach>
minion: Please tell MrtnDk[m] about SICL.
<minion>
MrtnDk[m]: SICL: SICL is a (perhaps futile) attempt to re-implement Common Lisp from scratch, hopefully using improved programming and bootstrapping techniques. See https://github.com/robert-strandh/SICL
Major_Biscuit has joined #lisp
galex-713 has quit [Ping timeout: 260 seconds]
<MrtnDk[m]>
beach Interesting. I don't know any alternative to UNIX / GNU+Linux, but I'm aware that there might be some short comings. Regarding Climacs2, I'm guessing you have to ditch Emacs Lisp to some extent.
<beach>
Er, yes, I am not planning to use Emacs Lisp.
<gabc>
What's the status of SICL? (it's not obvious from the github repo)
louis771 has quit [Quit: My M1 has gone to sleep. ZZZzzz…]
<beach>
gabc: Still not working.
<shka_>
i think that CL is strictly superior to Elisp anyway
<beach>
gabc: I am working on register allocation at the moment.
<shka_>
osicat loads fine after nuking away the .cache/common-lisp
<beach>
gabc: Most of the code has been executed and tested, though, thanks to the unique bootstrapping technique.
<gabc>
alright cool thanks! :)
<beach>
gabc: So the register allocator, the code generator, and the garbage collector are the modules that have not been tested, and won't be until we have an executable.
<gabc>
They can be tested in isolation I assume?
<beach>
I don't know. I haven't thought much about it.
skapata has joined #lisp
<beach>
MrtnDk[m]: I strongly recommend "The Unix Haters Handbook". I put off reading it for the longest time, thinking it was written by ignorant people, but in fact it was written by very smart and very knowledgeable people who knew better alternatives that preceded.
warweasle_afk is now known as warweasle
<gabc>
Okok I haven't look too much into SICL, I looked at some of his paper but nothing more
<beach>
"his"?
<gabc>
oh sorry, Robert Strandh
<shka_>
beach is Robert
<beach>
Er, "beach" is a literal translation of "strand"
<gabc>
ahahah
<gabc>
Well
<gabc>
"yours" then :P
<shka_>
he is the man himself
<gabc>
Oh damn
<gabc>
Well that's awkward
<MrtnDk[m]>
Strand is another word for beach. 😁
<beach>
gabc: Don't worry about it.
<gabc>
Aah a german word
<beach>
In this case, Swedish, but yeah.
remby has joined #lisp
<Nilby>
I've been slowly addressing every issue in "The Unix Haters Handbook".
<MrtnDk[m]>
Are you a Swede?
jbgg has left #lisp [#lisp]
<beach>
MrtnDk[m]: I am a citizen of the European Union. My passport says my nationality is Swedish, but that's just a technical thing. I am French for all practical purposes, and my current best language is English.
<beach>
MrtnDk[m]: I have lived in 5 countries on 4 continents.
<MrtnDk[m]>
beach Which operating system are you using (since CLOSOS probably isn't ready for main stream yet).
<beach>
I am currently using Ubuntu GNU/Linux, and I am upset with it on a daily basis.
<Nilby>
beach: Me too.
<shka_>
somehow i had less problems with arch linux even then the ubuntu
<shka_>
don't know what is wrong with it
<Nilby>
After trying fixing the same problems for years one's annoyance tends to snowball.
<beach>
shka_: I can imagine that. What I need is a system administrator who will give me the environment I would like to see, among the available choices.
<MrtnDk[m]>
Which problems are you having?
varjag has quit [Quit: ERC (IRC client for Emacs 26.3)]
<beach>
MrtnDk[m]: That I have to restart Firefox when the code is updated. That I have to restart the operating system AND all my applications when the kernel is updated. That everything is written in silly static languages that are hard to deal with. That everything runs in a separate process so that communication is hard.
<beach>
MrtnDk[m]: That they are making my life harder by introducing things like ASLR (and worse) to patch problems that should be fixed by a complete rethink of the computing model.
<MrtnDk[m]>
ASLR?
<gabc>
MrtnDk[m]: Address space layout randomization
<beach>
gabc: Thanks!
<gabc>
(I did google it just faster :P)
<beach>
MrtnDk[m]: Much of what I am saying here is more elaborate in the CLOSOS document.
<MrtnDk[m]>
Wow, you're fast gabc
<gabc>
MrtnDk[m]: I've been confused for a bot a few time in my life ¯\_(ツ)_/¯
sabasedigh has quit [Changing host]
sabasedigh has joined #lisp
<beach>
Heh.
<jackdaniel>
wait, aren't you a bot?
<gabc>
jackdaniel: You can prove either way, and I won't spoil
<MrtnDk[m]>
beach Sounds like an ambitious project. I am guessing SICL is a precursor for it.
<Nilby>
gabc is extraordinarily advanced for a bot
<beach>
MrtnDk[m]: Correct.
<Josh_2>
beach: perhaps you should try an LTS instead, no need to update
<beach>
MrtnDk[m]: In particular, first-class global environments are essential for it.
<beach>
Josh_2: That's basically my "solution" to the problem, yes.
<Josh_2>
I just switched to Devuan which is a fork of Debian because I don't like updating. Everything it uses is LTS
<beach>
Josh_2: But I am a researcher, and just knowing that they messed things up this bad makes me upset.
<Josh_2>
:P
<Josh_2>
I think I will checkout The Unix Haters Handbook
<beach>
The saddest part is that the vast majority of users think Unix is the best, not only the best there has every been, but the best there could be. So they live perfectly happily in this misery.
Inline has joined #lisp
<Josh_2>
well right now there are only 3 real world choices, windows, mac and linux, so I think in those circumstances linux is the best
<beach>
That's true.
<gabc>
Heck Plan9 is a better Unix than Unix is
<beach>
But notice I didn't say "the best there is". I said "the best there has ever been".
<admich>
beach: there is some relation between Mezzano and your closos? Is Mezzano a unix-like OS written in CL or is it something near your idea?
<beach>
admich: They are unrelated. Mezzano is great, but does not have any of the explicit goals that I have for CLOSOS.
<beach>
admich: And, no Mezzano is not a Unix-like.
<beach>
I haven't actually used it, but I think it can be thought of as a Common Lisp system on bare metal.
flazh has joined #lisp
aartaka_d has quit [Read error: Connection reset by peer]
aartaka has joined #lisp
<beach>
froggey: Is Mezzano crash proof? If so, what technique do you use?
remby has quit [Remote host closed the connection]
<semz>
The Unix Hater's Handbook is strange. I read it twice; the first time I dismissed it, thinking "wtf are these people whining about". The second time I found myself agreeing with basically everything. But I have no idea how or when I went from 1 to 2.
<beach>
semz: That sounds very plausible to me.
<gabc>
The foreword of Dennis Ritchie is quite funny tho
aartaka_d has joined #lisp
aartaka has quit [Ping timeout: 245 seconds]
Inline has quit [Read error: Connection reset by peer]
sabasedigh has quit [Ping timeout: 264 seconds]
Inline has joined #lisp
varjagg has joined #lisp
narimiran has joined #lisp
sabasedigh has joined #lisp
louis771 has joined #lisp
louis771 has quit [Client Quit]
louis771 has joined #lisp
orivej has quit [Ping timeout: 256 seconds]
OlCe has quit [Ping timeout: 256 seconds]
<MrtnDk[m]>
Is it true it comes with a barf bag? I seem to remember that ...
<beach>
I believe so.
<beach>
I read it online, so I didn't get it.
<Xach>
I own a copy and can confirm it comes with a barf bag. (Mine remains unused.)
sabasedigh has quit [Changing host]
sabasedigh has joined #lisp
OlCe has joined #lisp
<ck_>
mine as well
<ck_>
if I feel sick, I just apply X Windows directly to the forehead
notzmv has quit [Ping timeout: 264 seconds]
MrtnDk[m] has quit [Ping timeout: 268 seconds]
louis771 has quit [Quit: My M1 has gone to sleep. ZZZzzz…]
arcontethegreat[ has quit [Ping timeout: 268 seconds]
jonatack has joined #lisp
contrapunctus has left #lisp ["Disconnected: Replaced by new connection"]
contrapunctus has joined #lisp
DateMasamune2000 has quit [Ping timeout: 245 seconds]
MrtnDk[m] has joined #lisp
arcontethegreat[ has joined #lisp
varjagg has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
raeda has quit [Quit: Leaving]
sabasedigh has quit [Quit: ChatZilla 0.9.93.2017081717 [Basilisk 52.9.2021.03.17/20210317091816]]
aartaka_d has quit [Read error: Connection reset by peer]
aartaka has joined #lisp
sabasedigh has joined #lisp
sabasedigh has quit [Changing host]
sabasedigh has joined #lisp
admich has quit [Ping timeout: 245 seconds]
amk has quit [Remote host closed the connection]
amk has joined #lisp
rogersm_ has joined #lisp
rogersm_ has quit [Remote host closed the connection]
Inline has quit [Ping timeout: 240 seconds]
frost-lab has quit [Quit: Ping timeout (120 seconds)]
rumbler31 has quit [Remote host closed the connection]
emacsomancer has quit [Quit: WeeChat 3.0.1]
rumbler31 has joined #lisp
emacsomancer has joined #lisp
Major_Biscuit has quit [Quit: WeeChat 3.0.1]
<Odin->
The Unix-Haters Handbook is an interesting artifact. Not least because the same sorts of (and, indeed, in some cases _actually_ the same) people that whined about it are now whining about things like systemd changing the systems they know.
ljavorsk has quit [Ping timeout: 245 seconds]
metehan has quit [Remote host closed the connection]
<MrtnDk[m]>
Odin- I remember looking at UNIX haters handbook at one point, I guess to dismiss it. I don't remember what my reaction was, but I think I'd prefer a system like rc init (is that what it is called?) over systemd. Systemd seems like a big beast, that is hard to control. So from a KISS point of view, I'm not sure it's an improvement. I'm not really that invested, so someone might sway me.
galex-713 has joined #lisp
tiwEllien has quit [Ping timeout: 264 seconds]
Nilby has quit [Ping timeout: 258 seconds]
<Odin->
MrtnDk[m]: The point actually isn't about systemd as such; it's more that there's a certain irony in Unix people scoffing at the (real or imagined) inferiority of different systems, after having been so very adamant that everyone who used to do that in their direction was silly for doing so.
shka_ has quit [Quit: Konversation terminated!]
imuo has joined #lisp
<imuo>
(waves 'me)
<fiddlerwoaroof>
\o/
<MrtnDk[m]>
Odin- I get it now, I think.
<imuo>
i feel the calling to make a forum for an interest i have. i really enjoyed the phpBB forums of the past (as a user)... but as a programmer... i am curious.. is there a lispy version?
<imuo>
i am already familiar with the basics of hunchentoot (sp?)
<MrtnDk[m]>
I have a common question. A common Lisp question even. The question is, how do I do iterative Lisp, without getting the warning about redefining a nested defun? Is there a different way (a common way) to do this in common Lisp?
<jasom>
MrtnDk[m]: don't have nested defuns?
shka_ has joined #lisp
<fiddlerwoaroof>
MrtnDk[m]: "defun" is only a toplevel form, there's FLET and LABELS for locally-defined functions
<jasom>
MrtnDk[m]: what is it you think you need a nested defun for?
<MrtnDk[m]>
jasom That's what I figured. I was looking for an alternative. I guess fiddlerwoaroof just have me a couple ..
<MrtnDk[m]>
gave*
<MrtnDk[m]>
jasom: I come from Scheme.
<fiddlerwoaroof>
I always found SICP's use of nested defines weird
<fiddlerwoaroof>
There aren't any parens to tell you what the scope of the definition is
<jasom>
MrtnDk[m]: you can also use e.g. (defconstant +x+ 3) instead of (let ((x 3)) (defun FOO ...) (defun BAR ...)); this covers a different case than what fiddlerwoaroof suggested
OlCe has quit [Ping timeout: 256 seconds]
<jasom>
is there already a portable wrapper around OS CSRNG (arc4random, getrandom, /dev/urandom, whatever windows uses)?
<MrtnDk[m]>
fiddlerwoaroof It seems like I have trouble with the syntax of label. SBCL complains about unbound variable <function name> ..
<jasom>
MrtnDk[m]: also be aware that PROGN doesn't count as nesting for the purposes of top-level forms, so you can e.g. have a macro that expands to (progn (defun ...) (defun ...))
<jasom>
Alfr: I was hoping something that didn't involve pulling in all of ironclad; should have specified that
rpg has joined #lisp
<MrtnDk[m]>
jasom: The pasting doesn't seem to work for me; but w3m complains about a cookie it had to reject ...
Lycurgus has joined #lisp
midre has quit [Ping timeout: 244 seconds]
<jasom>
MrtnDk[m]: probably for anti-spam. Can use a different pastebin if you prefer
sauvin_ is now known as Sauvin
midre has joined #lisp
orivej has joined #lisp
imuo has quit [Quit: Connection closed]
Lord_of_Life_ has joined #lisp
<MrtnDk[m]>
jasom I was trying to figure out how to allow a cookie
* jasom
doesn't use w3m
Lord_of_Life has quit [Ping timeout: 256 seconds]
Lord_of_Life_ is now known as Lord_of_Life
rogersm has quit [Quit: Leaving...]
<shinohai>
MrtnDk[m]: Does yer w3m have some seekrit js support for it?
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rpg has joined #lisp
<MrtnDk[m]>
shinohai I dont think it supports JavaScript.
<shinohai>
I was just curious, as most paste sites I've tried work sporadically (or not at all) under w3m
<Shinmera>
plaster doesn't use any js spam prevention or mandate cookies, so dunno what's going wrong there.
<Shinmera>
There is a plaster.el package for emacs, though I don't know if it still works. Been a long time since I last tested it.
ljavorsk has joined #lisp
PuercoPop has joined #lisp
ljavorsk has quit [Ping timeout: 268 seconds]
mindCrime_ has joined #lisp
kevingal has quit [Ping timeout: 244 seconds]
<MrtnDk[m]>
Shinmera JSON readtable error: 60
<Shinmera>
I don't know what that means.
<jmercouris>
Come on, it’s obvious
<jmercouris>
/s
<jmercouris>
It’s JSON readable error: 60
shka_ has quit [Ping timeout: 264 seconds]
narimiran has quit [Ping timeout: 258 seconds]
srandon111 has quit [Remote host closed the connection]
srandon111 has joined #lisp
hiroaki has quit [Ping timeout: 240 seconds]
cage_ has quit [Quit: Leaving]
kini has quit [Quit: bye]
DHARMAKAYA has joined #lisp
kini has joined #lisp
DHARMAKAYA has quit [Ping timeout: 268 seconds]
hiroaki has joined #lisp
<rpg>
jmercouris: Now marked down to JSON readtable error: 59.95
<gabc>
To the moon!
raeda has joined #lisp
<MrtnDk[m]>
Shinmera I am guessing it means that plaster.el is broken. 😁
<Shinmera>
possibly.
<MrtnDk[m]>
It was just updated in 2018 however, so I did have hope it would work.
<Shinmera>
A lot can happen in 3 years.
<MrtnDk[m]>
Aparently, yes.
anticrisis has joined #lisp
OlCe has joined #lisp
rumbler31 has joined #lisp
unimog has quit [Remote host closed the connection]
aartaka_d has joined #lisp
rumbler31 has quit [Remote host closed the connection]
rumbler31 has joined #lisp
aartaka has quit [Ping timeout: 264 seconds]
aartaka has joined #lisp
aartaka_d has quit [Ping timeout: 268 seconds]
Krystof has joined #lisp
rumbler31 has quit [Remote host closed the connection]
akoana has joined #lisp
louis771 has joined #lisp
Inline has joined #lisp
<Xach>
rpg: hello! what projects does shop3 need that are not in quicklisp?
<Xach>
rpg: it is not described in the readme as far as i can tell
metehan has joined #lisp
metehan has quit [Remote host closed the connection]
metehan has joined #lisp
<rpg>
Xach: You mean what dependencies does it have? I don't think it has any.
<rpg>
It has a bunch of externals for people who do not use it with QL, but as far as I know it works just fine when added to QL as a local project.
<rpg>
Xach: Worded more clearly, "as far as I know all of SHOP3's dependencies are available through Quicklisp"
<fiddlerwoaroof>
rpg: are you a maintainer of ASFD?
<fiddlerwoaroof>
ASDF?
<rpg>
fiddlerwoaroof: Yes (for my sins).
<Xach>
rpg: > You need to do this, at least for the moment, because some of the required libraries are not in Quicklisp.
<fiddlerwoaroof>
Cool, I've always wondered why the define-ops returned by ASDF:LOAD-ASD don't seem to have any information about the system that was defined
<Xach>
rpg: i didn't understand that bit in the readme
<fiddlerwoaroof>
Is it possible to use them to somehow retrieve that information?
<rpg>
Xach: Let me look again. That may be obsolete.
<MrtnDk[m]>
I wonder how I: 1. Install the slime extension for quicklisp. 2. How I access the documentation for quicklisp.
varjag has joined #lisp
cosimone has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
<rpg>
Xach: OK, I see that. Yes, that is old.
OlCe has quit [Ping timeout: 256 seconds]
<rpg>
Xach: The new state of affairs is that there is one library that is not in QL -- pddl-tools -- and that is only used in the tests. The rest of the dependencies are all in QL now.
<rpg>
s/pddl-tools/pddl-utils/
<rpg>
I should make that one available, too; it's on GitHub (https://github.com/rpgoldman/pddl-tools) but there's one problem -- the repo contains four systems: pddl-utils, pddl, pddl-planners, and external-planners, and I don't know if that means I should re-package (decompose) it to be QL-friendly.
<rpg>
I suppose I should explain that recursing the submodules is *not* necessary when working with QL.
<Xach>
quicklisp recurses the submodules
akoana has quit [Quit: leaving]
<rpg>
Xach: Ah. Hm.
<rpg>
Xach: I fixed the README, but am not entirely sure how to fix the submodules issue. They are there to support CI on a bunch of projects. Is there any way to mark them as not being of interest to QL?
<rpg>
They are in my `jenkins/` subdirectory, to support CI, as the title suggests.
ljavorsk has joined #lisp
remby has left #lisp ["Good Bye"]
Lord_of_Life has quit [Ping timeout: 268 seconds]
gaqwas has quit [Ping timeout: 268 seconds]
surabax has quit [Quit: Leaving]
<alanz>
I see usages like "(:use #:clim-lisp #:clim)", and also "(:use :clim :clim-lisp)". I presume they are identical?
<no-defun-allowed>
Yes, they are identical in behaviour.
<alanz>
But I imagine the first one documents more clearly what is going on
<Shinmera>
does it?
<alanz>
or rather, is there a stylistic convention as to when to use which form?
<no-defun-allowed>
I use the latter for package names; they convey the same information.
<Shinmera>
The only difference is that the latter interns those keywords.
Lycurgus has quit [Quit: Exeunt]
<Shinmera>
I use the former, just because it costs me barely anything, but it really hardly matters.
<fiddlerwoaroof>
I like using keywords because then I can autocomplete them once they've been interned once
<alanz>
ok, so its no big deal. Is an interned keyword like an erlang atom? takes up space forever?
<fiddlerwoaroof>
But, also, don't use :use
<Shinmera>
alanz: until it's uninterned, sure.
<fiddlerwoaroof>
alanz: yeah, until nothing references it
<alanz>
This is copy/paste from mcclim Examples/views.lisp
<alanz>
ok, so you can undo it then. Great
<no-defun-allowed>
Keywords stick around until they are uninterned (like any other interned symbol).
kini has quit [Remote host closed the connection]
<alanz>
what should happen instead of :use?
<fiddlerwoaroof>
I think using :clim-lisp is ok (and intended)
<Shinmera>
:use is fine when it's expressly intended.
<no-defun-allowed>
Yeah, for CLIM you are supposed to (:use :clim :clim-lisp) as CLIM-LISP can patch up some Common Lisp functions.
<Shinmera>
otherwise, use fully qualified names, and package-local-nicknames if the package name is long.
<fiddlerwoaroof>
but, it's generally better to either write out package/symbol names or use :import :clim :define-presentation-types
<alanz>
ok, That was just a fragment out of the header section, to illustrate the #
louis771 has quit [Quit: My M1 has gone to sleep. ZZZzzz…]
kini has joined #lisp
* alanz
should read the packaging docs some time. Winging it at the moment. Cargo cult FTW
louis771 has joined #lisp
dhil has quit [Ping timeout: 256 seconds]
varjag has quit [Ping timeout: 264 seconds]
jonatack has quit [Ping timeout: 268 seconds]
villanella has quit [Ping timeout: 240 seconds]
pve has quit [Quit: leaving]
mindCrime has joined #lisp
mindCrime_ has quit [Ping timeout: 268 seconds]
notzmv has joined #lisp
sjl has quit [Ping timeout: 256 seconds]
Helmholtz has joined #lisp
OlCe has joined #lisp
ljavorsk has quit [Ping timeout: 245 seconds]
<jmercouris>
Why was symbolics named symbolics?
rodentrabies has joined #lisp
<no-defun-allowed>
Symbolic computation?
<jmercouris>
What does that even mean?
<aap>
it means you manipulate symbols instead of numbers
<jmercouris>
I don’t think that’s the meaning here
<jmercouris>
Seems very unlikely
<aap>
what?
<jmercouris>
I’m saying the name doesn’t seem to be derived from symbolic computation
<jmercouris>
There are plenty of languages that predate the formation of symbolics that supported symbolic computation
<aap>
but that's like the core idea of lisp
<aap>
so it seems extremely likely to me
<jmercouris>
Is that so?
<aap>
yes
<jmercouris>
Really?
<aap>
the whole point of lisp was to do symbolic computation
ljavorsk has joined #lisp
<jmercouris>
I thought the core idea of lisp is SEXP and list processing
<jmercouris>
Hence the name, LISP
<aap>
symbolic differentiation was one of the original problems
<aap>
well you gotta represent symbols somehow, that's where SEXPs come in
<jmercouris>
What is symbolic differentiation?
<aap>
like x^2 -> 2x
<aap>
differentiation mathematical formulae
<aap>
s/tion/ting/
<jmercouris>
X^2 -> (* x x)
<jmercouris>
How did you come up with 2x?
<aap>
that's the derivative of x^2
<jmercouris>
Oh that’s what you mean
<aap>
lisp was designed for these sort of problems
<jmercouris>
I see
<jmercouris>
Wonder why
<jmercouris>
FORTRAN seems just as capable
<White_Flame>
fortran doesn't have symbols?
<aap>
i dare you to write a program to do symbolic differentiation in fortran
<aap>
and i mean FORTRAN I
<aap>
or maybe II
<jmercouris>
I’m good
<jmercouris>
No thanks :-)
<jmercouris>
It’s just that Fortran bills itself as suited for numerical computation
<White_Flame>
jmercouris: exactly, and numerical computation is not symbolic computation. Fortran doesn't take equations at runtime in symbolic form and transform them
<jmercouris>
Doesn’t look like CL to me
<aap>
obviously not
<White_Flame>
mexprs!
OlCe has joined #lisp
<aap>
it's a sort of pseudocode. mexpr syntax was never fully specified i believe (certainly not when this paper was written)
<jmercouris>
Were there no languages at the time that supported this?
<jmercouris>
I find it really hard to imagine lisp was the first
<aap>
there was ipl but it was rather cryptic afaik. never looked into it much
<semz>
lisp is surprisingly old
<aap>
meanwhile lisp is super friendly, so it definitely was the right idea
<jasom>
jmercouris: 1959 I think?
<jmercouris>
I know it is old
<jmercouris>
I just find it hard to believe that nobody else was doing this
<jmercouris>
Feels very unlikely
<aap>
as i said, maybe look into IPL
<aap>
but other than that people were mostly writing assembly at the time