freenode/#lisp - IRC Chatlog
Search
6:53:52
Hiver
I found this (https://gist.github.com/endofinnsmouth/009a7a3a91b180371fea20cc983898ed) online, and it said it was an "nlp". What is that, and can you explain this program?
6:56:37
Hiver
just so i know what not to do though. what is bad about that code? I dont wanna fuck up. ooooooooooh and thanks
6:58:21
jackdaniel
line breaks are bad, it is not clear what functions do (not docstrings or comments)
7:03:27
Zhivago
That's just general advice -- but it also applies regarding people who can't spell "can't".
7:03:53
beach
Hiver: It uses SETQ to define special variable, but that is undefined behavior. And it does not use earmuffs on special variables, which is bad style.
7:08:08
jackdaniel
no, style is just a strong indicator it is not worth reading. program doesn't look useful either
7:12:05
Zhivago
They're trying to get intelligent people to ignore them so that they can focus on the stupid ones.
7:13:40
Zhivago
No. They just get the intelligent people to decide that the message is obviously a scam so that they then don't respond, which would waste the scammers' time.
7:15:01
Hiver
ooooh. ok. so, he wont come here because he is afraid of the advice? or is the program a scam?
7:15:09
Zhivago
The same process applies to software. Intelligent people avoid using software that looks like it was written by a twelve-year old who had been dropped frequently on its head as a child.
7:16:02
Zhivago
Which is generally a good idea, because software that looks like that probably hasn't been written carefully or well thought out, and the cost of maintaining it is high.
7:17:24
Zhivago
One problem is that to beginners, they are so bad at reading code that they can't distinguish between good code and bad code.
7:20:17
minion
Hiver: direct your attention towards pcl: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
7:22:41
Hiver
Also to respond to beach. He used to do a bit of Java (idk if it is true). Recently switched to LisP
7:22:59
beach
Hiver: Your friend should also learn to use an editor that can handle Common Lisp code so as to obtain correct indentation.
7:27:19
turkja
lol, why so harsh? it for sure looks like someone's first lisp program.. but it's a start anyways :)
7:38:25
vtomole
One of these days I'm going to have enough money to go to that Bay Area Lisp meet up and ELS.
7:44:51
jackdaniel
then you'll be able to say proudly at ELS: I'm here, because I've solved bunch of McCLIM problems
7:54:12
pjb
defvar and defparameter are top-level forms, you would never use them to set a variable. Use setf for that!
11:01:08
lisp_guest
i have a question about style. in this function (from yesterday) https://plaster.tymoon.eu/view/685#685
11:01:27
lisp_guest
this when bothers me a bit, because the usual way i would implement this is to have a check for the opposite and then just return early before proceeding
11:06:42
jackdaniel
I'm working on semaphores for BT (will try to merge it upstream if possible) – this is generic implementation (using cv): https://plaster.tymoon.eu/view/686#686 -- fallback for implementations which doesn't have semaphores
11:07:03
jackdaniel
I'd appreciate comment on this (for instance if I got it right) if someone have a slice of time
11:07:09
Shinmera
Especially since the return-from increases mental overhead by requiring the explicit function name, having an inverted check, and introducing an explicit control flow transfer.
11:08:26
Shinmera
jackdaniel: In fact, having a list is awful because it means you don't get a distinct type for the semaphore.
11:09:04
jackdaniel
because I would have to check somehow, if implementation has semaphores implemented "its way"
11:10:05
Shinmera
The implementation potentially providing its own semaphore object doesn't really change anything.
11:10:05
jackdaniel
there is bt:timeout type defined without such conditionalization, but SBCL with-timeout signals different condition – this is a source of many programmer errors
11:10:31
jackdaniel
I want to avoid such situation for semaphores, that programmer does check-type on bt:sempahore
11:10:32
Shinmera
jackdaniel: Make the struct named %foo and provide a deftype that aliases to the concrete type on each impl
11:11:25
Shinmera
I really don't think that any amount of implementation overhead is going to justify using a list
11:12:43
jackdaniel
I've explained initial motivation for such avoidance, I may reconsider (or change upon maintainer request)
11:13:55
loke
jackdaniel: if so, you could make it three-elemtn array instead? That'll make lookups fast.
11:17:29
Shinmera
His argument is that he would need to conditionalise the existence of the struct or type for each implementation if they provide their own native semaphore object type.
11:17:40
loke
Isn't his point that you shouldn't be able to do CHECK-TYPE (or whatever) on the object, becasue in specialised implementations the type of the object can be unpredictable?
11:18:26
Zhivago
It's rather then class can differ -- but CL has that leak back into the type for array, which sucks.
11:19:06
loke
That said, I'd like to see a custom type that is defined to be whatever the underlying impleemntation uses. That way I cal always use (CHECK-TYPE BT:SEMAPHORE) and it'll word regardless of implemnetation. Then a struct would be fine.
11:19:18
Shinmera
the solution is (defstruct %semaphore ..) (deftype semaphore #+sbcl 'sb-whatnot:whatever #-... '%semaphore)
11:20:04
jackdaniel
Shinmera: and where should I put this deftype, if implementation doesn't have native semaphore on %semaphore?
11:29:55
beach
lisp_guest: It is considered bad style to use WHEN in a situation where the value matters. It is better to use an IF and return NIL in the "else" branch.
11:30:30
lisp_guest
beach: so making explicit the fact that i want "nil" to be returned if sym is not a symbol?
11:36:41
Shinmera
beach: Sure. In this case one could argue that returning NIL on failure is an explicit property of WHEN so the return value of NIL is already explicit too.
12:20:41
basket
I started trying to write an Emacs mode knowing vaguely about EIEIO as a CLOS-like but discovered that it's single-dispatch and doesn't support around methods, very disappointing
12:24:30
scymtym_
basket: i think this is no longer true in recent emacs versions. the object system is much closer to CLOS now
12:46:33
pjb
lisp_guest: I use sprunge which is barebone and cool: #!/bin/sh  exec curl --silent -F 'sprunge=<-' http://sprunge.us  # cf. https://clbin.com/ 
14:49:25
beach
drmeister: He mentions simulations of molecules (as I recall) as one great application for quantum computing.
15:29:36
Devon
Anyone know how to (read-byte *standard-input*) and (write-byte * *standard-output*) portably?
15:40:50
beach
Devon: As far as I know, those are character streams, so you have to write characters to them.
15:42:00
pjb
Devon: implementation dependent, you may be able to use flexi-stream to change the kind of stream, or you may be able to create binary streams on the same file descriptors.
15:42:48
pjb
Devon: for command line tools, just pass paths to the binary files as command line arguments, and open them.
15:43:36
pjb
You can then bind them to *standard-input* and *standard-output*, but I would advise against it (just use parameter named input and output). Keep *standard-input* and *standard-output* for textual I/O, you may want to issue messages, etc.
15:49:49
pjb
Devon: there's also another consideration: this is a big no-no to touch *terminal-io* and the object bound to it. (it's the stream used to report errors and by the debugger by default). But by default *standard-input* and *standard-output* may be synonym-streams to *terminal-io*; so mutating the streams bound to those variables would mutate the stream bound to *terminal-io* and this would break the implementation!
15:50:25
pjb
So, rebinding *standard-input* and *standard-output* is allowed, but not mutating (eg. changing the element-type) of those streams.
15:52:12
Devon
Since it cannot be done portably, any implementation-specific solution could carefully mutate all the standard streams without breaking anything.
15:53:01
pjb
First try flexi-stream, as I answered above. (Despite your erroneous affirmation that no solution was proposed).
15:57:05
scymtym_
jackdaniel: in https://plaster.tymoon.eu/view/686#686 in WAIT-ON-SEMAPHORE: when going back to sleep via CONDITION-WAIT, timeout should be decreased by already elapsed time
16:00:22
jackdaniel
scymtym_: good point, thanks. current version is here: github.com/dkochmanski/bordeaux-threads/ , I will incorporate your remark later today
16:01:23
jackdaniel
I've switched to internal-real-time, generic implementation had small problems when tested on CCL with timeouts like 0.1