freenode/#lisp - IRC Chatlog
Search
18:30:31
dlowe
Xach: I also had to stop working on my one thing :) Maybe someday I can get back and rough it up some
21:17:37
thijso
Anybody familiar with android architecture? It's apparently a little different from normal linux (despite a lot of appearances), in that calling bt:join-thread just completely locks up your app. Nothing will ever happen after you call that, it seems. Or maybe I'm just doing something wrong.
21:18:12
thijso
But a long time debugging, and I've narrowed it down to that call. On ECL, that just does an mp:join-process under the hood. And then everything grinds to a halt...
21:22:45
thijso
Not really, no. It's one thread, and that finished pretty quickly. Exact same code runs without trouble on regular linux with ECL.
21:24:00
thijso
Yeah, no, as that is very hard to do running on my current setup. I'll have to look into getting swank running again. It's not as simple, because you need a specialized form of quicklisp and swank.
21:28:33
thijso
Not exactly sure what the function does, but it includes this comment: ;; replace interpreted function with precompiled one from DEFLATE
21:50:49
thijso
Hhmmm... might have spoken too soon. Had a bunch of code commented out in my 'working' version. Looks like the thread is actually dying in there somewhere...
21:53:40
Xach
asdf_asdf_asdf: because it has determined that the code cannot be reached and it does not need to be included in the compiled code
21:54:35
Xach
asdf_asdf_asdf: it is deleting the last form because your case always returns before the final form is reached.
21:56:00
Xach
asdf_asdf_asdf: your unconventional indentation makes it hard to see the control flow quickly.
22:04:23
thijso
Hmmm... does ECL do something different with vectors? Looks like (incf (size-of queue)) is dying.
22:09:59
thijso
Although, maybe it's dying on subsequent iterations. It's very irritating, as all my debugging output gets lost when it dies. So I can only figure out stuff when it *doesn't* die. Pain in the you-know-what...
22:37:10
gilberth__
asdf_asdf_asdf: Perhaps you first learn some Common Lisp and stop using it like you would use C.
22:37:56
Xach
asdf_asdf_asdf: there is no way for the control of the program to proceed past your CASE form. every outcome of the form results in control returning to somewhere else. no forms after it are reachable.
22:38:29
Xach
it is not an error to have unreachable code. but it is usually a sign of misunderstanding.
22:43:01
gilberth__
Or to put it otherwise, if you don't mind, Xach, in CL there is no need to RETURN-FROM a function make it yield a value.
22:47:36
gilberth__
ACTION is hacking in Lisp for over 30 years now and almost never uses RETURN-FROM.
22:50:11
Xach
asdf_asdf_asdf: no. but it is essential to understand how it works and how it affects control flow and why it might lead to unreachable code.
22:54:51
gilberth__
asdf_asdf_asdf: The one thing you really must get is, that Lisp does not distinguish between statements and expressions like most other languages do.
23:11:52
gilberth__
Xach: BTW I am not _that_ olde, CLtL1 was published as I was 10yo which was about the time I came into contact with Lisp.
23:15:59
gilberth__
But, yes, I wonder when was BLOCK/RETURN-FROM invented? I bet Zeta Lisp has that, too.
23:18:44
Bike
the other day i looked at the lisp 1.5 manual, and it has return, and prog has a block. no naming or dynamic extent or anything though
23:21:59
gilberth__
Standard Lisp is funny. It allows RETURN and GO in a tail position only. Calls for LABELS.
23:38:24
Bike
if i read it correctly it was even worse, like i don't think you could GO from a nested if
23:43:13
gilberth__
BTW, I often use "[x]" for quoting, since I simply cannot remember what to quote and what not.
23:44:12
gilberth__
And it's different in [POSIX] basic regular expression versus extended regular expressions.
0:06:19
minion
The URL https://gitlab.common-lisp.net/users/sign_in?secret=487355e5 will be valid until 00:15 UTC.
0:20:19
gilberth__
ralt: BTW your "\" is bogus. And a (FIND-IF (LAMBDA (C) (FIND C ".-_")) "foo-bar") is even faster.
5:18:41
thijso
the issue I thought was with incf yesterday, turns out it's me using (return) instead of (return-from label)
5:31:52
thijso
flip214: maybe. Doesn't feel like it. Especially as I haven't found the real issue yet.
5:48:15
thijso
pjb: yeah, I know. Still frustrating every time it happens. Especially when you end up with something working and you don't really know why...
5:49:02
thijso
So, why would it work if I wrap the call to the main app function in a mp:process-run-function? i.e. in a separate thread.
5:49:58
thijso
Although... maybe I need to clean up all my debugging code before I start rejoycing...