Search
Sunday, 10th of June 2018, 19:11:15 UTC
19:49:44
thodg
any hope for threads on sbcl/openbsd-i386 ?
19:52:44
akkad
thodg: #sbcl may be able to help. do rthreads only get supported on openbsd-amd64}
19:53:20
thodg
dunno if it's rthreads either
19:56:09
jurov
Anyone knows how to make quicklisp compile a system for debugging?
19:56:50
phoe
jurov: for debugging? you mean with debug 3?
19:57:28
jurov
ah, this looks like it: https://stackoverflow.com/questions/45730012/common-lisp-asdf-tests-compile-system-with-different-optimization-levels
20:03:38
phoe
jurov: remember that a system is able to override those.
20:03:49
phoe
use SB-EXT:RESTRICT-COMPILER-POLICY on SBCL.
20:04:56
jurov
phoe: it can be overriden somewhere else then .asd or .lisp file belonging to the system?
20:09:35
phoe
a Lisp file can contain (locally (declare (optimize (speed 3) (safety 0) (debug 0))) ....)
20:13:00
phoe
jurov: it is bad taste, but it happens.
20:24:32
thodg
akkad: probably rthreads yes =)
23:31:17
DataLinkDroid3
** NICK DataLinkDroid
23:47:50
slyrus1
phoe: isn't that actually standard practice for SBCL ffi calls?
1:37:49
Xach_
ACTION is in slyrus's neck of the woods this week
2:59:57
beach
Good morning everyone!
6:30:26
makomo
where does the standard explictily define dynamic and indefinite extents?
6:30:42
makomo
there's 3.1.6, but it doesn't give definitions for those
6:30:45
specbot
Extent: http://www.lispworks.com/reference/HyperSpec/Body/03_af.htm
6:40:41
spiaggia
makomo: It is defined in the glossary.
6:52:38
makomo
spiaggia: only there?
6:52:51
spiaggia
As far as I can see, yes.
6:53:04
spiaggia
I grepped for it in the TeX files of the dpANS.
6:53:52
makomo
i've looked at those and it's clear to me what they do i think, but i was still hoping for a larger explanation
6:54:10
makomo
usually the stuff that's in the glossary is defined somewhere in the standard explictily
6:54:14
spiaggia
Oh, you want an explanation? I can give that to you.
6:54:59
makomo
i think i understand the concepts because it's not so different from C++'s storage duration for example
6:55:10
makomo
it's the same concepts/issues regarding lifetime
6:55:29
spiaggia
I shall have to take your word for it.
6:55:32
makomo
but i thought there would be a bigger formal definition for them
6:55:35
White_Flame
it's also the definition that necessitates thread-local
6:56:06
makomo
White_Flame: oh i remember that conversation from the other day but i wasn't following closely. where does it do that?
6:56:15
White_Flame
but yes, RAII-style scope boundaries are basically equivalent to dynamic extent
6:56:39
White_Flame
makomo: in the glossary definition of dynamic extent
6:56:52
makomo
that's what one would call "automatic storage duration" in C++
6:56:52
White_Flame
other threads are not "within the execution of a particular form"
6:57:40
White_Flame
indefinite extent means that the language mechanics don't make a reference undefined
6:57:57
spiaggia
makomo: There is no mention of thread-local in the standard, simply because there is no mention of threads in the standard.
6:58:07
makomo
spiaggia: yeah, true
6:58:20
makomo
White_Flame: yup. i think of it as just because something that has been malloc'd but never free'd :-)
6:59:01
White_Flame
although the GC will eliminate non-referenced objects, which might fall in the same technical vocabulary
6:59:10
makomo
right, i was thinking of that
6:59:12
White_Flame
but it's still indefinite when that will happen
7:00:34
makomo
White_Flame: hm so, this implies thread-locality only if we assume the existence of threads and their usual behavior right?
7:01:07
White_Flame
"an extent whose duration is bounded by points of establishment and disestablishment within the execution of a particular form. "
7:01:37
White_Flame
depends on how you define "within" </bill clinton>
7:01:58
White_Flame
but thread locality is certainly compatible with that language
7:05:33
makomo
White_Flame: iirc, the whole discussion was started because of the question whether every thread has its own dynamic environment and whether they share the global dynamic environment?
7:08:54
makomo
hajovonta: how did you presentation go? :-)
7:09:53
hajovonta
makomo: I haven't hold it yet, first my colleague will do it on the topic of Prolog, this Wednesday as planned
7:10:05
hajovonta
I'll do it maybe next week
7:10:50
hajovonta
and we will have one on Erlang
7:11:00
makomo
you should also sneak a prolog implementation in lisp into your talk :^)
7:11:14
makomo
"remember that language from the last time? well here's a 50 line implementation"
Monday, 11th of June 2018, 7:11:15 UTC