freenode/#lisp - IRC Chatlog
Search
10:49:57
ogamita
nydel: yes, for now, it should be sufficient. But this doesn't address the specific UI problem of mobile. Terminal emulations are good, but you really want a physical keyboard connected to the mobile to do any serious work. (and then, it works well enough, ergonomically).
10:51:27
nydel
ogamita: may i ask what sort of work you do for a living (or for whatever) ... you're very admirably-skilled at brainstorming on the line between inside-box and outside-outer-space & i wonder the reason why
10:53:53
ogamita
I'm a free-lance developer. I can write programs for macOSX, iOS, Android, Linux. Currently I'm working on integrating Smartcard Login on FreeRDP for a customer. Next year, I'm starting a company to develop IA software.
11:00:26
nydel
"probably more for #lispcafe" is such a polite way to tell someone they're boring you
12:13:40
pfdietz
You could just build a new version of your lisp and it gets its own fresh slice of the cache. :)
12:16:17
pfdietz
If you build a new SBCL, with changes from previous, it will give it a new (lisp-implementation-version), which will go into a fresh subdirectory under .cache/common-lisp
12:18:37
jdz
I have not seen any variables named $1 or $2 when compiling my code. Probably the result of one of those lambda-shortening macros.
12:19:17
jdz
I don't know. You are the one compiling the code, you should know where they come from.
12:23:05
jmercouris
did you quickload each dependency independently to see if they would emit warnings?
12:23:13
pfdietz
I have cl-string-match here, and I used the magic of grep... like he said. Confirmed with (ql:quickload "cl-string-match" :verbose t) (which gives me 38 style warnings, btw).
12:23:18
jackdaniel
grep -rn "my error" ~/quicklisp/dists/quicklisp ; is the most effective silly way to find where warning comes from
12:24:39
jackdaniel
so grepping for the message (carefully, message may have i.e ~A and not the literal you see) is a good heuristic
12:25:29
jmercouris
ok, then my follow up question, anyone have any suggestions to replace cl-string-match?
12:26:42
jmercouris
yes, I'm getting the impression that cl-string-match is not a well taken care of lib
12:28:21
jmercouris
well there were some other interesting things it had in addition to regex, but I'm not using those
12:28:34
pfdietz
If you want to push up changes, I've forked a copy of it on github (added a new algorithm I needed).
12:28:43
jmercouris
and maybe when I wish to do those interesting things I may wish to implement them myself..
12:29:10
jmercouris
pfdietz: I would like to, but I don't want the overhead of having to coordinate to push to ql or maintain deps
12:29:53
pfdietz
This is NOT the version going into QL. I tried to get access to the server with the "real" repo, but had issues. So no pull requests.
12:29:54
jmercouris
I'm sure there is quite a bit that you would disagree with, I also don't like a lot of the source
12:31:58
pfdietz
Although suffix trees on general sequences, not just strings, would be nice (I've used that in clone detection algorithms).
12:40:33
pfdietz
I pushed a change to my copy of cl-string-match that gets rid of the style warnings (and fixes two tests).
12:41:25
jmercouris
I'm thinking about the convenience for users to have to clone your version to compile from source
12:41:59
pfdietz
The QL model with someone elses' dist is not really compatible with good configuration management.
12:48:41
jmercouris
I am thinking, why not just use quicklisp? and have a custom dist only with systems designed to work with next?
12:58:16
ogamita
quicklisp is quite dangerous, when you start to develop seriously. Imagine, you use a dozen libraries, and next month you update quicklisp, and half of them are removed from the distribution!
12:58:49
ogamita
There's quite some prunning occuring each month (I'm not saying it's unjustified, but if you depend on those libraries, you won't be happy).
13:08:08
pfdietz
Things get pruned when they stop working, so if you depended on them and they're removed, you'd probably be in trouble regardless.
13:23:42
beach
Where in the Common Lisp HyperSpec does it say that a DEFMETHOD form is evaluated in the normal lexical environment, as opposed to the null lexical environment?
13:27:34
beach
Yes, well, we are writing a paper about MAKE-METHOD-LAMBDA and I want to get things right.
13:33:02
ogamita
Implementations indeed do it, but I don't see it specified. I guess, they don't use make-method in defmethod or defgeneric…
13:36:45
ogamita
(but I agree, it's nice that methods defined by defmethod and defgeneric be closures).
13:38:00
ogamita
"The form used with make-method is evaluated in the null lexical environment augmented with a local macro definition for call-method and with bindings named by symbols not accessible from the COMMON-LISP-USER package."
13:38:57
Bike
but the form used with make-method is a part of the result of compute-effective-method. it doesn't have a method body in it.
13:40:22
beach
Now, here is the inconsistency: http://metamodular.com/CLOS-MOP/make-method-lambda.html
13:42:10
Bike
that make-method-lambda description also redefines how call-method and sort of how make-method works but doesn't have enough detail
13:44:42
beach
It says, The generic function and method the method function will be used with are not required to be the given ones.
13:46:11
Bike
yeah, ecl and clasp incorporated that, which removes one of the objections in costanza's paper
13:47:27
beach
The other objection is that the method-class must be known so the generic function must be known, or else a method of the wrong class will be created.
13:48:14
beach
But the compiler could save the :method-class argument to DEFGENERIC just as it might save the lambda list, without creating the generic function.
17:13:42
verisimilitude
If I were building an iOS or Android program for someone, I'd try to use mocl; the main issue is they're not so free with their documentation if you don't buy it, apparently, even if you ask nicely.
17:15:46
clintm
We inquired about using mocl for Android about three or four months ago and were told it had bitrotted. Let me see if I can find the email.
17:16:20
verisimilitude
I just wanted to look at its documentation for completeness' sake in a library I've written, but didn't even receive a response.
17:18:42
clintm
Ok, so, sort of bitrotted. Constant changes to android studio, and the (lone?) developer now works at a full time job that doesn't involve mocl.
17:31:42
Xach
selling cl tools always seems like a tough row to hoe, i was hoping mocl could make it work
17:36:10
jasom
I'm curious how LTO works with clasp, since lisp lacks anything quite like a link time
17:36:25
jackdaniel
just saying, but ECL also exists, works on android and you while it has some rought edges you are physically able to fix these because it is a foss software
17:37:35
verisimilitude
I'm fortunately spared from iOS and Android development, but I'd use ECL or SBCL if I couldn't get the employer to buy mocl, yes.
17:38:34
verisimilitude
That does have me wondering, jackdaniel; mocl advertises its special declarations for linking to the native code well; does ECL have anything comparable to those?
17:40:09
jackdaniel
I don't know what are mocl's special declarations for linking, but ECL shares runtime with other C programs
17:40:39
jackdaniel
so it may be linked to other program, compiled to shared and static library and such
17:44:35
clintm
jackdaniel: Do you happen to know of any projects that try to tie the android UI with ECL? I wouldn't expect it to be part of ECL itself, but I looked around when we were evaluating our options and didn't find much in the way of projects, examples, or the like that did anything with the UI.
17:44:54
jackdaniel
it doesn't have Apple's Xcode integration, but it allows defining lisp functions which are called like other C functions
17:45:44
jackdaniel
EQL5-Android project developed it further and has great demos with user interface
17:45:55
clintm
Oh yea, I think I messed with that on one of our test devices! It worked quite well, as I remember.
17:46:52
clintm
Ohh, right, is that the one that needs the specific version of the ndk? Not saying that's a problem or anything, it's just been three or four months since I was poking at this.
17:47:31
jackdaniel
the one I wrote requied specific ndk version because the newer one had some bug, but it was around 2y ago, I would suspect it should work now
17:48:03
jackdaniel
and if not pull requests are welcome and source is available (if it is ecl fault)
17:48:15
clintm
Hrm, yea, I built and messed around with that. I may have to dig into it again - I can't remember why I passed on it.
17:48:16
jackdaniel
here are screenshots: https://gitlab.com/eql/EQL5-Android/tree/master/screenshots
17:50:06
clintm
Yea, right! I built the skoban and repl examples, installed and ran them and they worked as advertised as I remember. Ok, now I'm really curious. Time to shave some yaks and set it up again.
17:50:11
jackdaniel
the most notable drawback with ECL on android is that usually you are forced to use bytecompiler at runtime (nothing technical, devices just usually doesn't have gcc), but you may load precompiled libraries
17:50:50
jackdaniel
and the second drawback is generic function dispatch performance. we plan to address that after upcoming release
17:50:57
clintm
I don't remmeber that being a problem, but I also don't remember doing anything special because of it.
17:58:56
jackdaniel
we know how to improve it (thanks to beach papers and clasp team experimentation)
17:59:55
jackdaniel
I'd say drmeister, but there are more developers who do teremendous job with it (for instance Bike)
18:07:12
Bike
i'd like to see about inlining method bodies themselves so it's like a real jit, but that's a lot of work
18:07:40
drmeister
Yeah - it's not all me anymore. Bike is doing a tremendous amount - Cleavir was written by beach. kpoeck has been fixing lots of bugs. The list goes on.
18:11:22
Bike
i guess rather than full method bodies it's accessors really, or maybe gfs more generally
18:13:14
Bike
it would be pretty cool for accessor calls within methods to be turned into inline memorhy accesses
18:40:56
pfdietz
another-user: that is, if you're using one the standard equality functions (eq, eql, equal, equalp), so it can build a hash table for membership testing.
18:42:08
another-user
pfdietz: yeah, i would like to get "012" from (loop for i from 0 to 2 collect (format nil "~a" i))
18:42:09
verisimilitude
The first thing that comes to mind is collecting into a list and then using COERCE, another-user.
18:42:26
pfdietz
Not directly, but you can set up an extensible character vector with a fill pointer and use vector-push-extend.
18:43:13
pjb
another-user: (coerce (loop for i from 65 to 74 collect (code-char i)) 'string) #| --> "ABCDEFGHIJ" |#
18:43:36
pjb
another-user: but actually: (with-output-to-string (out) (loop for i from 65 to 74 do (write-char (code-char i) out))) #| --> "ABCDEFGHIJ" |#
18:44:04
pjb
another-user: or: (with-output-to-string (out) (loop for i from 65 to 74 do (format out "~D " i))) #| --> "65 66 67 68 69 70 71 72 73 74 " |#
18:45:12
verisimilitude
I always use *STANDARD-OUTPUT* as the symbol bound with these types of macros.
18:45:39
pjb
If you do a single collection at a time, yes. But giving another name let you collect several strings at once.
18:45:49
verisimilitude
Then you don't introduce an unnecessary symbol into the system and you can type less.
18:46:26
verisimilitude
I've yet to run into a nesting situation such as that, pjb, but that would be an example of when not to necessarily do it, yes.
18:47:42
pjb
(block nil (with-output-to-string (odd) (return (values (with-output-to-string (even) (loop for i from 65 to 74 do (write-char (code-char i) (if (oddp i) odd even)))) (get-output-stream-string odd))))) #| --> "BDFHJ" ; "ACEGI" |#
19:04:57
verisimilitude
I suppose I may work more on my ACUTE-TERMINAL-CONTROL and clean my CL-ECMA-48 of unnecessary symbols a tad before the year's end, seok.
19:08:43
drmeister
I'm implementing compile-file-parallel - it compiles AST's in serial and then tosses the AST->native code compilation into threads. I'm seeing contention and so I'm exploring ideas on how to track down the source and fix it.
19:10:00
drmeister
Clasp's stacks are pretty deep and we blow through the bullsh*t 512 frame limit of Xcode's Instruments - what a load!
21:18:11
jasom
it won't show you directly, but you should see threads spending a lot of time in lock acquisition
21:18:55
jasom
if you don't have a good one, just break all threads into the debugger randomly a dozen times and see what locks are contended (if contention is more than half the problem, you should see 5 or more of the same lock contended)
21:19:39
jasom
drmeister: not easy to tell from that graph; depending on the lock implementation you get very different CPU profiles for contention
21:20:03
jasom
e.g. some userspace mutexes will spin a few times before blocking, others will always do a syscall even in the non-contended case
21:20:53
jasom
shouldn't need to look at backtraces; the lock acquisition code should be on the top of the stack when waiting
21:22:07
drmeister
I mean when I use dtrace I get lots of backtraces and the lock acquisition should be at the top of the stack in many of them.