freenode/#lisp - IRC Chatlog

Search
4:04:12 jeosol morning beach
4:04:23 jeosol good morning beach
4:06:13 asarch Is the content of HyperSpec Lisp the same as "ANSI Common Lisp" book?
4:07:33 skidd0 no
4:07:45 skidd0 ANSI Common Lisp by Paul Graham?
4:08:40 asarch Yeah, that book
4:10:27 beach asarch: Yes, the Common Lisp HyperSpec has only minor differences compared to the ANSI standard.
4:11:03 beach asarch: But Paul Graham does not mention the full language.
4:13:25 asarch What do you mean with "the full language"?
4:13:49 beach The book is too thin to mention every function, every macro, every class, every special form.
4:13:59 asarch I see
4:15:48 asarch Since I already know Kung-Fu, I was thinking to get a book about, for example, "how would I parse a file reading only...?" to check those functions related
4:16:25 asarch There is a package of HyperSpec Lisp in OpenBSD ports
4:17:02 asarch The Common Lisp HyperSpec (TM) from LispWorks Ltd. The Common Lisp HyperSpec is a hypertext version of the ANSI Common Lisp
4:17:02 asarch standard.
4:17:48 asarch clisp-hyperspec-7.0.tgz
4:18:26 beach Almost, but not quite. The standard is owned by ANSI and not even LispWorks has the right to create a derived work from it. However, the draft standard is available for everyone to use, and there are only very minor differences between the draft and the final standard.
4:18:46 asarch Is it expensive the standard?
4:19:06 asarch I mean, could I buy a copy and then use that info as reference manual?
4:19:15 beach Maybe. And they lost the source so they only sell badly scanned copies of it.
4:19:29 asarch D'oh!
4:19:31 asarch Really?
4:19:35 beach What is it that you want to do?
4:20:05 asarch The STL (for C/C++) reference manual for Common Lisp?
4:20:11 beach For all practical purposes, the Common Lisp HyperSpec is the reference. Except if you want to include it in the bibliography of a paper or a book. Then you need to refer to the standard.
4:20:33 beach Again, what is it that you want to do?
4:20:41 beach Create a manual and publish it?
4:20:46 beach Just use it on your machine?
4:20:48 asarch No, for my personal use
4:20:55 beach Then copy the Common Lisp HyperSpec.
4:21:11 beach LispWorks explicitly gives you the right to do that.
4:22:05 asarch Just the same I did with the PCL web: to get a hard copy and then read it every time I want to know something specific
4:22:21 beach Oh, you want a paper version?
4:22:26 asarch Yeah
4:22:39 beach Then use the dpANS draft. It is in TeX format and it is free to use.
4:22:58 beach Someone recently did a script to create a complete PDF for it.
4:23:18 asarch YESSS!!!
4:23:26 asarch Thank you beach, thank you very much
4:23:35 asarch Why it is a "draft"?
4:23:39 asarch A draft about what?
4:23:43 asarch ACTION takes notes...
4:23:53 beach "draft" means "not the final version".
4:24:07 beach It is the version that was distributed for people to comment on.
4:24:36 beach The contents is identical to that of the Common Lisp HyperSpec, because LispWorks used the draft to create the Common Lisp HyperSpec.
4:25:09 beach asarch: Are you sure you want that though. It is around 1000 pages as I recall.
4:25:50 asarch :'-(
4:26:36 asarch Every page cost $0.3 with large volumes here in México
4:26:55 asarch I could ask full duplex for that
4:27:37 asarch Is still the Meta Class System available in Common Lisp?
4:27:49 beach ?
4:28:01 beach What is the "Meta Class System"?
4:28:42 asarch I found a paper about it
4:29:08 beach Do you have a reference?
4:30:00 asarch Sure. I am uploading the file to the Mega cloud
4:31:14 beach The title, the authors, and the abstract would be enough.
4:35:16 asarch Sorry, medical emergency. I'll post you later
4:51:17 beach minion: memo for asarch: Here is a site that has a full PDF of the standard: http://cvberry.com/tech_writings/notes/common_lisp_standard_draft.html and it contains 1360 pages (rather than the 1000 I was guessing).
4:51:18 minion Remembered. I'll tell asarch when he/she/it next speaks.
4:51:37 beach Sorr, of the DRAFT, not of the standard.
4:51:42 beach y
5:16:33 LdBeth The ANSI standard can be obtained for $60, but I don’t see there’s much difference in contents, and it’s a photo scanned PDF.
6:15:55 asarch Bleh! Mega server doesn't work on OpenBSD
6:15:55 minion asarch, memo from beach: Here is a site that has a full PDF of the standard: http://cvberry.com/tech_writings/notes/common_lisp_standard_draft.html and it contains 1360 pages (rather than the 1000 I was guessing).
6:16:10 asarch Thank you!!!
6:16:16 asarch Thank you very much :-)
6:16:36 asarch Could I e-mail you the paper about MCS?
6:17:34 asarch "Many people apparently use the Common Lisp Hyperspec, but I personally find this document highly confusing and difficult to learn from in any meaningful way." <- I thought I was the only one
6:19:58 beach Sure, you can email it to me.
6:20:36 beach The Common Lisp HyperSpec is not meant to be learned from. It is meant for people who implement Common Lisp systems.
6:20:56 beach Also as a reference document for those who already know how to use Common Lisp.
6:24:16 beach asarch: I am off for a while. Back in a few hours.
6:24:21 asarch Sure
6:24:26 asarch Have a nice day :-)
6:24:31 asarch Thanks for the link
6:52:41 phoe 1991. That's before the standardization.
6:52:50 phoe And before the inclusion of CLOS in the standard, obviously.
7:03:48 asarch D'oh!
7:04:29 asarch That was my next question: "who was first, MCS or CLOS?"
7:04:34 asarch Anyway, thank you phoe
7:04:37 asarch Thank you very much :-)
7:16:01 LdBeth asarch: CLOS is very late, before it is CommonLoops and Flavor
7:17:23 LdBeth asarch: but obviously MCS is after CLOS
7:33:45 asarch Is MCS still alive?
7:39:12 asarch I guess not
7:39:31 asarch CLOS is now the defacto standard, isn't it?
7:39:54 _death it's also the de jure standard..
7:50:34 asarch I see
7:50:48 asarch Thank you
7:50:53 asarch Thank you very much
9:45:46 pjb ** NICK Guest24137
9:50:17 puchacz hi, will sorting be faster if I am only interested in top N elements? and have we got library for it?
9:51:59 beach Definitely faster. I am not sure there is a library for it.
9:52:04 beach Is it a list or a vector?
9:52:16 puchacz I can make it a vector
9:52:38 beach A displaced array might work.
9:55:27 beach It seems to work.
9:55:38 puchacz beach, what did you do pls?
9:56:09 beach (defparameter *v* (make-array N :displaced to <original-vector>))
9:56:15 beach Then (sort *v* #'...)
9:56:33 beach er, :displace-to
9:56:41 puchacz so how does it take into account that we want top N?
9:56:57 beach See the argument to MAKE-ARRAY?
9:56:59 beach it is N
9:57:06 puchacz ah, ok :)
9:57:42 puchacz thanks!
9:57:50 puchacz I have another related problem
9:58:11 beach Don't we all?
9:58:11 puchacz I can run few database SELECTs, each can be ORDERed BY
9:58:48 puchacz and then I want top N from concatenation of result.....
9:58:57 puchacz mind that each resultset is already sorted
9:59:27 puchacz (sort (reduce #'append result-sets :from-end t) sorter-func) seems soooo wasteful
9:59:27 _death if you're interest in the top N elements, then you don't need a full sort.. I'm not sure what a displaced vector has to do with it
9:59:40 shka1 puchacz: merge it
10:00:02 puchacz shka1: "merge sort" as a name of algorithm rings a bell
10:00:12 beach _death: It selects the top N elements.
10:00:13 shka1 yeah, but not merge sort
10:00:16 shka1 just merge
10:00:51 puchacz how?
10:00:57 beach clhs merge
10:01:02 puchacz ah, thanks
10:01:08 _death beach: suppose you have #(1 3 2 4) and you need the two largest elements.. how would that work?
10:01:38 beach Oh, maybe I misunderstood.
10:01:49 Guest24137 _death: you would have to implement your own algorithm to drop the elements you don't want.
10:01:52 Guest24137 ** NICK pjb`
10:01:54 beach By "top N" I assumed the first N.
10:02:07 puchacz top N - N largest elements
10:02:17 beach Oh, sorry then.
10:03:02 _death I think a heap structure may work
10:03:05 pjb` ** NICK pjb
10:03:38 puchacz shka1: merge does not let me take top N either
10:03:41 beach Yeah, that or quicksort but recursively sorting only half.
10:03:47 shka1 puchacz: write your own
10:03:57 shka1 merge-into or something like that
10:04:04 puchacz shka1: it seems I will have to
10:04:14 pjb Actually, you can collect the N biggest elements in O(M). then sort them in O(N*log(N)).
10:04:36 beach What is M?
10:04:46 puchacz pjb: true. I think pjb means N, not M
10:04:48 shka1 number of vectors
10:05:04 pjb with M=(length vector) and N being the top N parameter.
10:05:17 puchacz okay
10:05:22 puchacz I should try
10:05:24 puchacz thanks!
10:11:57 hhdave_ ** NICK hhdave
10:27:52 johnnymacs Is garbace collection in the lisp specification
10:28:31 beach No.
10:28:47 johnnymacs Then the satement "lisp is not suitable for kernel writing because it has garbage collection" iis objectively false.
10:29:10 johnnymacs However if you said "sbcl is..." then it is techincally true unless you edit sbcl to not have garbage collection
10:29:14 johnnymacs afaik
10:29:32 beach Yes, the person who uttered that would have to come up with a reason why kernels could not have garbage collectors as well.
10:29:37 pjb For example, Movitz is a CL implementation without a GC.
10:29:45 pjb Since it was designed to write kernels…
10:29:52 random-nick also, Mezzano is an OS with garbage collection
10:29:53 beach pjb: Oh?
10:30:15 pjb Which disproves the above statements two ways.
10:30:19 johnnymacs One could argue because it is so expensive to port all linux software to a new and radically different kernel and because it is also so expensive to add garbage collection to the linux that they refuse to accept it
10:30:28 johnnymacs *to a new kernel
10:30:57 beach johnnymacs: That's a different argument all together.
10:31:07 johnnymacs Indeed
10:31:08 jackdaniel johnnymacs: I think that what the claim really is (as in sense - means) is that language without manual memory managament is not suitable to write kernels. I don't have opinion on that, just pointing out that taking causal claims verbatim and 'disproving' them is not especially ahrd
10:31:30 johnnymacs thoughough that particular argument has to do with real world logistics thus making it more complicated than abstract things like the hyperspec
10:31:37 beach johnnymacs: While garbage collection is not in the specification, in practice you must have it.
10:31:38 johnnymacs lots of mutable state involved in indsutry
10:32:29 beach johnnymacs: So "SBCL is ..." is not technically true either.
10:32:36 johnnymacs sure
10:32:58 johnnymacs What would you say to someone who thinks a kernel should not have garbage collection
10:33:12 pjb Give a good reason why?
10:33:28 jackdaniel that he might be right, but there is no evidence for that
10:33:33 beach johnnymacs: That he or she would have to make an argument for it, and that argument would be easy to poke holes in.
10:33:33 johnnymacs Well I don't know why they think that because I am not a kernel writer. I was hoping you would have a guess as to why they think that
10:33:50 johnnymacs Do you have an idea of what arguments they commonly give?
10:33:51 pjb Notice that linux, minix, etc all have a whole module consacred to memory management.
10:34:10 beach johnnymacs: Many people think that GC is slower than manual memory management, or that it must have long pauses. Neither is true.
10:34:25 jackdaniel johnnymacs: one argument could be GC pauses; another could be overhead (and kernel must be as fast as it can) etc. of course these are arguable
10:34:35 beach johnnymacs: So it usually shows the ignorance of the person in question.
10:34:59 beach jackdaniel: Tracing GC is typically way faster than malloc()/free().
10:35:04 johnnymacs True but when I argue with them they will call me ignorant and their friends will be convinced they are right and all gang up on me asking me for evidence
10:35:28 beach johnnymacs: Oh, I strongly advise you to avoid such an argument.
10:35:54 beach johnnymacs: Instead, just ask questions...
10:35:55 johnnymacs The thing is i am really strongly convinced that SBCL is a superior language than most languages but it is hard to convince others of it.
10:35:57 jackdaniel beach: could be, I'm not familiar with the subject enough to argue. I could guess, that some tradeoff exists, i.e long pauses OR moderate overhead
10:36:23 beach johnnymacs: "Why do you think GC is unsuited?"
10:36:40 beach johnnymacs: "What makes you think necessarily has GC has long pauses?"
10:36:51 johnnymacs I still do not think I am at the point where no matter what answer they give I will have a comeback demonstrating gc is just as suited
10:36:56 beach johnnymacs: "What makes you think that real-time GC is impossible?"
10:37:12 beach johnnymacs: That's why I say, don't answer, just ask.
10:37:14 johnnymacs You can ask that question because you possess the knowledge to poke holes in their argument
10:37:22 pjb Basically, it's like you're comparing two 400 m runners. They argue whether you're taking the inside lane or the outside line, and whether you have crocheted shoes or not. But lisp just cut straight thru the grass toward the finish line.
10:37:24 puchacz shka1: thanks for the link
10:37:47 beach johnnymacs: No, just answer that you would like to see the reference.
10:38:22 beach johnnymacs: Just don't be satisfied with the "Oh, everybody knows that" answer.
10:38:23 johnnymacs beach: invariably if I do not fully undestand or not if the reference proves garabge collection is bad I will have to come hear for your evidence for why it is a hole in thair argument
10:38:30 johnnymacs until I stop coming across holes I can not identify
10:39:33 beach johnnymacs: I strongly advise against arguing. Just ask them to justify. In the end you can accept the argument if you like, or come back later with a pointer to an article that says the contrary.
10:40:08 beach johnnymacs: Like if they say "real-time GC is not possible", you show them (later) the chapter from the book or an article about it.
10:40:13 johnnymacs I consider it worth my time to convince the world of the speriority of languages which are written in compliance and according to the philosophy of the common lisp hyperspec until more efficient yet equally capable hyperspec comes along.
10:40:51 johnnymacs Or even a more capable hyperspec which is unlikely unless we invent a new kind of computer.
10:40:54 beach johnnymacs: You are wasting your time. People won't let themselves be convinced that easily.
10:41:18 jackdaniel ACTION doesn't believe in superiority among incomparable (in sense of aesthetics, functionality, hackability etc) languages
10:41:33 johnnymacs Let me express this then
10:42:12 jackdaniel also this may be a bad strategy to convert people to the language you like: your language sucks because mine is better (in essence!) ;-)
10:42:32 johnnymacs brainfuck is as superior as lisp because you can use brainfuck to write a lisp compliant with the common lisp hyperspec and run it. However it takes more work to do that in brainfuck than it takes to do it in sbcl thus making sbcl the victor. And if you are in braknfuck and you don't add in the capabilities of common lisp it objectively is worse thanc common lisp.
10:42:36 beach johnnymacs: The psychological barriers are just way too great. You are asking people who spent many years of their life investing time and energy into a particular technology to admit that they made the wrong choice. Our brains have very strong mechanisms preventing that.
10:43:08 johnnymacs First of all I think anyone who is willing to listen to evidenc and has the capacity to understand lisp will given enough tiem see the truth about lisp if explained to them with the right algorithm.
10:43:27 johnnymacs Second of all I find humans to be a resource which should be allocated to lisp instead of python whenever possible.
10:43:29 pjb Most languages are not intrinsically bad (thinking of C here). But people using them may be bad (or ignorant). Trying to convince them using a better programming language won't necessarily make them better, just bring bad programmers to the good language…
10:43:31 johnnymacs or schem
10:43:32 beach johnnymacs: That just isn't true.
10:43:32 johnnymacs either one
10:43:39 johnnymacs beach: which?
10:43:53 beach johnnymacs: That people are rational and will listen to argument.
10:44:09 jackdaniel "brainfuck is objectively worse than CL" – I throw at you argument: if someone is amused with using brainfuck (for fun), and tired with writing CL, then given "fun" criteria CL is *worse* than brainfuck for that particular person
10:44:09 johnnymacs There is a probability as to how rational a person can be for how long.
10:44:39 beach johnnymacs: Have you read my essay on the psychology of learning?
10:44:56 johnnymacs beach: you can send it to me but I do not have time to read it right now
10:45:06 johnnymacs could you state what you think is a true reaction to my statement
10:45:59 johnnymacs If not I can try to demonstrate how the human mind is capable of reason.
10:46:24 beach I have already said what I think. There are strong psychological forces that will make it very hard for you.
10:46:34 johnnymacs Almost every time I fail yes.
10:46:56 beach Not your fault.
10:47:08 johnnymacs I also try to spread lispy ideas covertly
10:47:16 beach johnnymacs: That's a much better idea.
10:47:22 jackdaniel well, it might be the attitude. I really believe that "your language is inferior to my because"
10:47:32 johnnymacs I often tout langauges which fall more closely to the paradigms fo lisp: javascript, c#
10:47:32 jackdaniel is not the best strategy ;)
10:47:46 jackdaniel s/my/mine/
10:47:48 beach johnnymacs: I consider myself fairly knowledgeable in these domains, but I gave up trying to argue with people a long time ago.
10:48:51 johnnymacs Here is how I see it. My goal in life is to improve computers as much as possible before I die. I see every line in languages such as python or php for example to be wasted because there is a near guarantee that there are such flaws in the designs of these langauges that they have no choice but to retire their respective compiler projects at some point.
10:49:07 johnnymacs Thus humanity's man hours are wasted and makes us more vulnerable agaisnt alien attack because our computers advance more slowly
10:49:17 johnnymacs This is the same reason why I promote bsd/gpl etc
10:49:32 beach johnnymacs: The only strategy that I have found that works is to do good work in the language that you prefer, and hope that people can see that it is better than theirs.
10:49:46 JuanDaugherty given the generational turnover/attrition rate it's especially pointless, dumb
10:50:11 JuanDaugherty wait the boogers out
10:50:12 johnnymacs I find it easier these days to move people to languages closer and closer to lisp. I go online and post as random people and say lisp ideas.
10:50:25 johnnymacs My most touting goes towards javascript.
10:51:20 johnnymacs I also tell people alfonzo church beat alan turing to the punch.
10:51:46 beach You might want to check his first name.
10:51:54 jackdaniel you can never predict which language will be a stepping stone for progress. Let's imagine C and UNIX were never invented, and that PC idea never took off. That'd lead to less tinkerers and programmers; also that'd lead to no SBCL ;)
10:51:55 johnnymacs noted
10:52:12 pjb Alonzo Church says wikipedia.
10:52:13 jackdaniel of course that's one of possible scenarios
10:52:18 johnnymacs The other thing is that yes we are writing in all these langauges that will be thrown away. And the objectively best languages, schem and lisp, are both langauges for writing languages inside of.
10:52:27 johnnymacs And so we dont need to be wasting any of our code like that
10:52:37 johnnymacs I can't allow humanity to waste all of our smart people
10:52:54 JuanDaugherty Alfonso, alonso, schlemeil, schmazel
10:53:00 johnnymacs Al
10:53:03 johnnymacs Al C.
10:53:18 jackdaniel good you are not a dictator, I'd be forced to write in Lisp! ;-) laters :-P
10:53:30 JuanDaugherty *schlmazel
10:53:38 johnnymacs If I were a dictator I would burn intel.
10:53:43 johnnymacs First move
10:53:57 pjb Start you own company, be the CEO/CTO and dictate lisp to all your hires.
10:54:04 johnnymacs Then I would put IBM in charge of all government computer stuff
10:54:28 random-nick why IBM?
10:54:29 johnnymacs Heck maybe I would even do whatever I wanted and then when I was done give the world to the ceo of ibm
10:54:31 beach ACTION goes to take a nap and hopes this discussion will be over by the time he wakes up.
10:54:42 johnnymacs yeah its off topic sure
10:54:44 johnnymacs bye
10:55:07 JuanDaugherty well he was the main topic enforcer
10:55:58 JuanDaugherty so now we can have a long digression on IBM
10:57:05 JuanDaugherty ACTION thinks about what the MVS lisp product must have been like
11:02:22 puchacz beach: sorry, is realtime gc possible ;)? not trolling, just curious - despite 2 decades of java in the mainstream, and major companies backing it, it did not happen....
11:02:55 JuanDaugherty in effect it's a moot point
11:03:35 JuanDaugherty people with little experience charge off on tangents without bothering to find shit out because they heard this or that
11:04:24 JuanDaugherty try actually observing how much time a well behaved sbcl system using the ordinary generational gc spends in gc
11:04:58 JuanDaugherty and nobody is proposing or shouldn't be, writing device drivers in common lisp
11:06:08 jackdaniel JuanDaugherty: RT is about deadline guarantees, not about throughput; as of drivers, I don't see a reason why they couldn't be written in CL (or other high level language)
11:06:28 JuanDaugherty OK
11:08:08 JuanDaugherty the burroughs machines did use algol for everything including device drivers but that's a special case
11:08:35 shka1 JuanDaugherty: that was few decades back i think :-)
11:08:54 JuanDaugherty not sure what lisp machines did but imagine they used some machine lang some lisp
11:11:07 jackdaniel puchacz: there are at least two commercial RT GC for JVM according to https://en.wikipedia.org/wiki/Tracing_garbage_collection#Real-time_garbage_collection
11:11:34 puchacz ok
11:21:34 jmercouris +1 on what jackdaniel it is possible to write a driver in Lisp, it would just probably be a bit harder, from my understanding, most drivers are copy/pasta'd forks of old drivers with modifications depending on how the device has changed
11:21:57 jmercouris so in Lisp you wouldn't have the advantage of all the previous code you could copy/pasta
11:22:02 jmercouris s/pasta/paste
11:26:26 jmercouris beach: I've noticed its been several months since any progress on climacs, is that because you are focusing on SICL's GC?
11:32:44 jmercouris beach: McClim does work on OSX, indeed using X
11:32:55 jmercouris what is the motivation for trying to do a 'native' port?
11:33:30 jmercouris is it for reasons of performance?
11:40:50 jackdaniel ftr, it is McCLIM; as of writing drivers, it is more about support from the underlying operating system
11:41:29 jackdaniel I was writing Linux drivers and it's far from copy-paste, it is mostly about using: a) exisitng abstractions; b) datasheets; c) other documentation
11:42:05 jackdaniel to part a) is crucial wrt writing drivers in Lisp. I think all Mezzano drivers are written in Common Lisp
11:45:32 jmercouris beach: jackdaniel: would there be any interest in updated graphics for McCLIM?
11:45:48 jackdaniel define "updated graphics"
11:46:08 jackdaniel I'm working on a set of gadgets following material design guidelines if that's what you talk about
11:46:20 jackdaniel if you are interested in helping then I'm all ears ;-)
11:47:00 jackdaniel rendered in CLIM, not gimp or anything
11:48:02 jmercouris I'm not interested in material design
11:48:11 jmercouris if you are interested in making a set of graphics that look good, I'm willing to help
11:48:25 jackdaniel graphics for what?
11:48:29 jmercouris unfortunately the intersection of graphics that look good, and material design have no overlap
11:48:52 jmercouris well, I don't know what your terminology is, but I refer to things as widgets
11:48:52 jackdaniel graphics are merely a tiny bit of design, so I'm not sure what you are after
11:48:55 jmercouris so for example a button
11:49:05 jmercouris how does a standard McCLIM button look like, what does a pane look like
11:49:11 jmercouris these are things I would be interested in working on
11:50:14 jackdaniel portable gadget set will follow what I've said above for a good reason: there is specification for it - not opinionated "I think that looks better" metodology
11:50:36 jmercouris the material design specification is not the only design specification in the world
11:50:43 jmercouris it also happens to be one of the worst ones in the world
11:51:01 jackdaniel but nothing prevents you from adding your own gadget set; I'll do my best to guide you with techinicalities in McCLIM
11:51:05 jmercouris "google makes great looking products" - no one ever
11:51:36 jackdaniel if it is good and complete I see no problem with including it, I have other interesting projects too, so I don't feel a great urge to force my idea here
11:51:53 Josh_2 idk Google products look pretty nice imo
11:51:53 jmercouris ok, where can I begin reading
11:52:11 jackdaniel *but* if you are only willing to complain, that what I'm working on doesn't look good to you, then it is a different story
11:52:15 Josh_2 Like Google Docs, Android, Gmail, they all look nice
11:52:43 jmercouris jackdaniel: I am only willing to complain? I've released a large amount of software and patches on the internet, complaining is just one of the things I do
11:52:50 jmercouris and if you take a criticism as a complaint, then as you wish
11:53:05 random-nick jmercouris: "gadgets" in McCLIM are things like buttons, sliders, text input fields and such
11:53:07 jmercouris It is objective that material design is terrible
11:53:31 jackdaniel I've just provided a disclaimer, that I'm not interested in debunking your own convictions, but if you are willing to create a portable set of gadgets for McCLIM I can help
11:54:07 jmercouris jackdaniel: Sure, I can provide all of the assets and specifications
11:54:11 jackdaniel and I really thing, that anyone who claims that something is *objectively* best/terrible/whatever when taken in terms of aesthetics, or a preference, is not very competent or honest
11:54:23 jackdaniel I'm not interested in assets and specifications, I'm interested in code which works
11:54:28 jmercouris jackdaniel: Computer Science is one thing, design is another
11:54:57 jmercouris Anyways, sounds like you want to someone implement the actual gadgets, which means there does not exist a current way to theme McCLIM
11:55:16 jmercouris which also leads me to believe that the current gadgets are implemented in code, and not really composed of bitmaps or anything that can be modified
11:55:19 jackdaniel I've linked you a few starting points, then there is #clim channel. the gist of it is to inherit from existing gadget and define handle-repaint method
11:55:46 jmercouris Ok, I will investigate
11:56:06 jmercouris I appreciate the vote of "incompetence"
11:56:57 jackdaniel sure
11:57:07 jmercouris That was sarcastic
11:57:15 jmercouris Just to be clear, I don't appreciate it at all
11:57:24 jackdaniel ah :(
11:57:51 jackdaniel Josh_2: imo they look good too, and take many important aspects into account
11:58:27 jmercouris Most certainly, that's why designers the world over are using google products, and hailing them for their fantastic interfaces
11:58:36 jmercouris Again, I'm being sarcastic, but what do I know
11:58:50 jmercouris I'm done ranting
11:59:57 Josh_2 being able to have customizable graphics is a good idea
12:03:22 random-nick jmercouris: well, the idea is to have the backends provide gadgets from the platform's native widget toolkit
12:04:04 random-nick and then to have fallback portable gadgets implemented in lisp using clim functions
12:04:06 jmercouris random-nick: so that's the idea behind having different backends?
12:04:53 jackdaniel there are three layers of it. portable toolkit should be possible to use on any backend and adaptive toolkit (optional) is backend specific
12:05:28 jackdaniel there are three layers of it. portable toolkit should be possible to use on any backend and adaptive toolkit (optional) is backend specific
12:05:36 jackdaniel ops, sorry
12:06:18 jackdaniel backends are for different platforms (display servers): Xserver, Wayland, GTK, Cocoa, WinAPI etc
12:06:55 jmercouris so any backend can, or cannot be used with any toolkit?
12:07:03 jmercouris I assume a portable toolkit can be used with any backend
12:07:07 jackdaniel any backend can be used with portable toolkit
12:07:22 jackdaniel but adaptive toolkit is backend-specific
12:07:25 jmercouris but a specific toolkit eg. cocoa might only be usable on OSX backend
12:07:35 jackdaniel i.e you use native GTK buttons - you can't use them on raw WinAPI
12:07:49 jmercouris I see, and how do you deal with differences in the specifications of those widgets?
12:07:50 jackdaniel yes
12:08:03 jackdaniel gadgets have strictly functional specification
12:08:13 jackdaniel how they look and are used is not defined in a standard
12:08:25 jackdaniel portable toolkit provides some example implementation of abstract idea
12:08:31 jmercouris Okay, but for example, let's say a specific type of callback exists in one implementation, but not another
12:08:33 jmercouris what do you do then?
12:09:12 jmercouris for a special type of button press
12:09:15 jmercouris as an example
12:09:27 jackdaniel abstract gadgets in CLIM specification have limited protocol of things which happen
12:09:42 jmercouris and that protocol is limited enough that it encompasses all GUI toolkits without gaps?
12:09:43 jackdaniel which should work on all platforms. you have all abstract gadgets listed in the specification I've linked about
12:09:47 jmercouris or at least the ones you wish to target?
12:10:18 jackdaniel it presents "common" gadgets with their usual functionality
12:10:31 jackdaniel it is possible that some existing toolkit doesn't support some of it, or that it supports more of it
12:10:50 jackdaniel of course nothing prevents the programmer from defining his own gadget
12:11:01 jackdaniel if adaptive toolkit can't produce it, then portable implementation is used
12:11:04 jmercouris I see
12:16:27 pjb puchacz: real time java garbage collection happened several times. Here is the one by IBM, but other company propose other RTGC implementations for the JVM.
12:19:29 jeosol syntax question: do you guys use '/' in variable (slot) names for example, I have a numeric quantity that a ratio of current value over initial value, then the variable name will be current/initial. Good/bad/doesn't matter
12:20:07 jackdaniel looks OK to me
12:20:20 jeosol thanks jackdaniel
12:20:56 jeosol current-inital-ratio seems a bit long, but current/initial seems shorter. not sure if others code this way.
12:21:16 jeosol I'll go with the / variant
12:22:44 pjb puchacz: it's rather lame to affirm things without using google first.
12:23:15 pjb jeosol: yes, you can have fun. (let ((1/2mv2 (* 1/2 m v v))) …)
12:23:49 pjb jeosol: you can also use unicode, all current CL implementations support it. (let ((½mv² (* 1/2 m v v))) … ½mv² …)
12:24:15 pjb jeosol: for lexical scopes, it doesn't matter much.
12:28:10 jeosol pjb: Thanks for the info especially with unicode. The code reads more natural that way. My variable names are numeric quantities in equations.
12:28:28 jeosol reads more natural this way and spot mistakes. Merci
12:29:35 pjb jeosol: if your code has a lot of formula, you could implement a reader macro to let you format your code like in HAL/S.
12:30:48 pjb An alternative would be to use a reader macro just as a marker for emacs, so that it can read the expression, format it with LaTeX, and compose it over the source.
12:31:19 pjb Something similar can be done for more complex expressions.
12:32:06 pjb This means that you would still type or edit sexps, but you would see the nice formated and rendered expression in the emacs buffer.
12:33:15 jeosol Wow, that would have been very useful. I had to write code to compute volume of arbitrary grid, it was a bit messy due to the many equations.
12:33:30 jeosol s/grid/grid-cell
12:47:45 beach puchacz: Yes, it is possible, but there would be more overhead. Just as if you wanted a real-time malloc()/free() which would be even harder.
12:48:35 beach minion: memo for jmercouris: Yes, I have been busy with SICL specification stuff.
12:48:36 minion Remembered. I'll tell jmercouris when he/she/it next speaks.
12:52:24 pjb jeosol: in the worst case, what you can do is to write a CL macro that will scan the formula in your math book, run OCR on it, and translate it to a lisp sexp. The whole at compilation time.
15:28:31 beach flip214: Around?
15:30:37 beach flip214: For root pointers, I just made a rule that if any invocation has a pointer to a rack (to the beginning of it, or to any element of it), then it must also have a pointer to the header. That other pointer is then subject to register allocation just like everything else. I just have to make sure it is not eliminated even though it is "dead". It would very likely migrate to the stack of course.
15:40:16 flip214 beach: yes.
15:40:36 flip214 for a few minutes, at least.
15:42:11 flip214 what's the question?
15:42:45 beach You suggested I store header pointers in the thread object. I am suggesting an alternative.
15:43:07 flip214 what "invocation" would that be? a GC run?
15:43:21 beach No, anything that creates a stack frame.
15:43:25 flip214 ah, okay.
15:43:26 beach Any function, basically.
15:44:24 flip214 well, the important thing is that there's a defined space for per-thread root pointers; and as registers are likely to contain arbitrary integer values, they might become false positives.
15:44:42 flip214 so storing on the stack looks okay.
15:44:43 beach No, they can't.
15:45:08 beach The compiler emits information that says whether a register or stack location contains a Common Lisp object or not.
15:45:16 flip214 although that means that you might need additional stack space, which might become a problem for deep recursive calls.
15:45:44 flip214 oh, so you go that way. Fine too -- sounded just like more work to me, but what do I know?
15:46:04 beach That will be a problem anyway, because I would need space in the thread object for arbitrarily many pointers.
15:46:10 beach Might as well store them on the stack.
15:46:22 beach The stack is cheaper too.
15:47:13 beach More work? How?
15:47:40 flip214 beach: no, at most one per register.
15:48:00 beach I don't see that.
15:48:01 flip214 "more work" as in "the compiler needs to tell the GC which register store pointers at which point in time"
15:48:21 beach Oh, that's just implementation work. No more work at run time.
15:48:54 beach Suppose for a moment that every register is a caller-saves.
15:49:12 beach Now, you have a function that accesses the rack of some object o1.
15:49:22 beach But it no longer needs the pointer to the header.
15:49:42 beach So you store the pointer to the rack on the stack and then you call another function.
15:50:03 beach That function needs a pointer to the rack of some object o2.
15:50:21 beach So you store that pointer on the stack and then call a third function.
15:50:24 beach etc, etc. etc.
15:50:42 beach You now have rack pointers in 3 stack frames, but no header pointers.
15:51:11 beach If I were to store those header pointers in the thread object, I would need one such location per stack frame, so not a bounded number.
15:55:11 flip214 But if o1, o2 etc. are no longer needed, what do you need the rack pointers for? To speed up GC because it knows which racks are in use?
15:56:04 beach OK, suppose I do (+ (aref x (f a)) (aref x (g b)))
15:56:49 beach To access the elements, I no longer need the reference to the header. Just a pointer to the rack. So when (b b) is called, there would normally be no reference to the header.
15:57:53 flip214 oh, I'm sorry. I think I got the terminology wrong - the "rack" is the "object" in SICL, right?
15:58:05 beach No the header is *the* object.
15:58:14 beach But it doesn't contain any information other than the class.
15:58:32 beach So if there is no pointer to the header, the object will be reclaimed by the GC.
15:58:52 beach Sorry, the header contains the class and a pointer to the rack.
15:59:30 beach I need to go fix dinner. I'll talk about this some other time.
15:59:36 flip214 beach: me too.
15:59:55 flip214 If your paper is in (kind of) shape, I'd like to read it again.
16:00:12 beach OK, great.