freenode/#clim - IRC Chatlog
Search
4:01:00
loke
Further back, there was also no standard spelling of Swedish, which is why in old texts you can see all kinds of spelling variations of the same words. It was a mss. In 1801 there was a major normalisation of spelling, but the 1906 one is where the H got removed in most places.
4:02:02
beach
I have a further suggested spelling reform. Spell all the "sj" sounds with "w" and all the "tj" sounds with "x".
4:02:40
beach
And spell "taxi" as "taksi" instead to avoid confusion. That's already how it is spelled in Finnish I believe.
4:04:04
loke
beach: Who not simply use ɕ and ɧ? THose are the IPA symbols for the sounds, are they not?
4:06:07
beach
Those are on most Swedish keyboards, I think. And if not, latin-1 input mode can do them easily.
4:06:32
loke
Interesting quote from Wikipedia: 1800-talets förslag att förenkla stavningen av j- (g, dj, gj, hj, lj) och sje-ljudet (stj, skj, sk, sch, sh, ch, g, j, i, ssi, si, ti, gi) har aldrig genomförts. Senare tiders försök till förändringar har gällt enstaka ord som mej, dej, jos, sebra, men har inte varit framgångsrika
4:07:48
loke
I remember when "jos" was used, really ugly, and and it's not just be being an old fart. I was in my teens when that happened.
4:09:49
beach
Why do you accept "sky" (i.e. juice from meat, jus in French) but not "jos" (i.e. juice from fruit, juice in English, jus in French)? The two are the same words.
4:12:19
loke
I think, at least for me, I have an aversion to the letters "jo" in the beginning of a word.
4:21:01
loke
beach: Hmm.... Not as bad actually... Perhaps the subsequent H makes it more palatable to me?
7:53:13
scymtym
working on package-based colors and timeline for thread and temporal interval selection: https://techfak.de/~jmoringe/clamegraph2.png
7:56:00
scymtym
jack_rabbit: it shows an approximation of the times spent executed functions and their all of their callees
7:56:45
scymtym
a flamegraph visualization of statistical profiler results for multiple threads if you are familiar with the terms
7:57:25
scymtym
jack_rabbit: not yet. it relies on modifications in SBCL profiler and i started working on the visualization part, like, staturday
9:40:36
scymtym
i have to say, even though this is barely usable at the moment, the experience is already completely different from profiling with slime or SBCL's builtin tools
9:41:33
scymtym
playing with the thing for 10 seconds and i immediately see a few curious things i want to investigate
9:42:00
jackdaniel
scymtym: when you are done, I'd love to include screenshot of it on McCLIM website, or even a gif image showing interaction
9:44:14
scymtym
i will try to make a demonstration because i'm never sure whether i'm just doing it wrong
9:44:48
jackdaniel
regarding growing pane automatically and making bounding-rectangle clipped, I think I need some time to think whenever we are not breaking something
9:45:17
scymtym
beach: i can probably make available a reasonable version after two more SBCL releases. i had to extend the profiler to record time- and thread-related information
9:46:40
scymtym
jackdaniel: sure, so far i find clim awesome but very confusing at the same time. i'm sure those things are hard to figure out
9:49:52
loke
CLIM is neat, but it's not good for general purpose UI's. There are plenty of UI paradigms that CLIM is not good for.
9:50:34
loke
It's because of that client I was talking to you about having a word-wrapping text editor
9:51:01
jackdaniel
I think that it is possible to bend McCLIM interfaces with extensions into something more bearable to commoners, but that requires careful design
9:52:39
jackdaniel
OK, I have things to catch up, whole morning wasted for server resuscitation. it happens that one of OVH datacenters had serious network issue
9:52:50
loke
beach&JD: am I correct in my assertion that there currently is no way to have a simple way of inputting multiline word-wrapped text? (i.e. the text input for a Mastodon post)
9:54:29
jackdaniel
if it just a matter of modyfing text-output-streams, then adding word-wrap is easy (I know that after investigating race issues and recording)
9:55:07
beach
loke: If you require the wrapping to change when the window is resized, then you are right.
9:56:22
jackdaniel
I think that initial loke solution to call redisplay on resize may be a good fit for *some* applications or gadgets
10:00:16
loke
beach: During resize would be nice, but I was specifically thinking of the case where you type too much to fix in the width of the input box. I'd like there to be a word-wrap so that the ext continues on the next line. Currently, the cursor just keeps moving outside the bounds of the text box.
10:03:07
jackdaniel
it is, and text wrapping in input boxes isn't trivial at all. because you may remove characters, so it must support unwrapping as well
10:24:20
loke
I was browsing the source code for DREI earlier, and if I'm not mistaken, there is no support for wrapping?
10:27:17
loke
jackdaniel: Thank you. That means that when I go back to my project, I can try to figure out a way to hack it together.
10:27:42
loke
jackdaniel: Right. That's the one I was looking at. It supports multi-line, but no wrapping (you have to manually press RET)
10:28:47
loke
The ideal would be something like the Android TextArea. It allows you to set max and min number of lines. It starts at MIN and will grow if needed until MAX. Then it adds scrollbars.
10:29:37
loke
So at some point I will work on adding some kind of wrapping to the multiline textarea
10:31:29
jackdaniel
McCLIM scrollbars take space (unlike android ones), you may add scrolling pane without scrollbars though
10:44:19
loke
jackdaniel: Right. Although it's not the scrolling that's the main issue for me. It's the need for wrapping behaviour.
13:02:19
beach
nyef: You have worked on the SBCL compiler, right? I have some questions about where to find information about compilation-related topics. Can I bounce some of them on you?
13:05:39
beach
I am trying to do some control-flow analysis in the presence of nested functions. For example, I need to know when a nested function can be inlined in its caller. I was wondering whether there are some research papers on the topic, or if at least we have some common terminology to talk about things like this.
13:09:41
beach
Ultimately, I would like to determine other things, like whether lambda lifting is possible.
13:10:08
nyef
Most of my practical compiler knowledge, unfortunately, comes from working on SBCL, or from books that you probably already have (the Dragon Book, Muchnick, and so on).
13:11:12
beach
OK, how about this: I write things down, and show it to you. Then you can see whether what I write is common knowledge and perhaps point me to sources of information?
13:12:31
nyef
Actually, what happens if you reverse the question? When can a local (nested?) function *NOT* be inlined?
13:13:45
nyef
And, even then, does that mean "there must be a non-inline copy", or "there can be no inline copy"?
13:14:22
scymtym
it is for ml but mostly about inlining, closure conversion etc. static types always don't play any role
13:14:48
beach
scymtym: My bet is that we are better off with a more traditional notation, like a graph of instructions.
13:16:57
beach
nyef: It is worse than that. If a reference to a nested function is passed to an unknown external function, and that function creates multiple threads, then an arbitrary number of invocations to the nested functions can be live simultaneously.
13:17:36
beach
And if the nested function side effects a variable in its parent, all bets are off with respect to the data flow of that variable, so type inference is not possible, etc.
13:18:29
beach
Such variables might have to be excluded from SSA processing, type inference, etc, etc.
13:18:34
nyef
So, the rough rule of thumb is that any function that "escapes", even if it escapes "downwards" may need to be treated specially as far as its closed-over variables go?
13:19:34
beach
It "may" indeed. But to find out whether it escapes, a control-flow analysis is needed, and to accomplish such an analysis, one needs to know whether a closure escapes.
13:21:48
beach
I do not want to believe dynamic-extent declarations, and instead try to infer as many as possible of those situations.
13:22:43
nyef
Mmm. Be careful there. I screwed up at least one release of SBCL with a broken analysis of some sort in this direction.
13:23:25
beach
That is exactly what I am trying to be, i.e. careful. Hence my question in the first place.
13:25:33
beach
Anyway, thanks. I think I'll continue my thinking, write it down, and submit it for scrutiny. If you feel like looking at it, that would be great. Otherwise, no worries.
13:26:40
beach
I'll invent some terminology as well. If it turns out later that there is established terminology that differs, I'll just adapt.
13:40:04
nyef
Hrm. Found the phrase "lowest common dominator" in a commit message, but that's in reference to STACK analysis.
14:25:07
nyef
beach: The "escapes to another thread" thing has a couple of implications. One is that if there's thread communication going on over closed-over variables then there needs to be appropriate synchronization. Detecting that synchronization might be useful somehow.
14:27:54
nyef
Another is that it doesn't necessarily completely blow out type analysis. Yes, it can be run any number of times at any point post-escape, but there's still the synchronization rules to deal with, which say how the runs interact more generally.
14:50:28
beach
As an example of complex control flow, I came up with the function F in this paste: http://paste.lisp.org/+7P28
14:51:03
beach
Because X is assigned to in G, then all bets are off what X is going to be at any point in time.
14:52:18
beach
H can create any number of threads that call G at any point in time with any argument. So we don't even know that X is the same between two FUNCALLs, or even between two argument evaluations in a single funcall.
15:26:45
nyef
You invoked "threads" as a reason for indeterminacy, but there is no thread synchronization in this function.
15:27:39
nyef
And, as system designer in the absence of a standard model for thread interactions with the language you are implementing, *you* get to pick the semantics.
15:28:41
nyef
No thread synchronization around X, and no thread synchronization in the control-flow paths that could affect X? Devolve to the uni-thread case.
15:33:31
beach
Even with no threads, the value of x can change between two FUNCALLs, and we can't determine the type.
15:44:33
nyef
beach: Actually, we have a bound on the type, though I'm not completely sure where we're permitted to enforce it: It's a FUNCTION.
15:46:34
beach
OK, here is another piece of information. In SICL, I don't intend to trust type declarations.
15:47:12
beach
Anyway, this is not what I wanted to discuss. It was just an example of where type inference must not be applied to X.
15:47:54
beach
jackdaniel: Think LispOS. I can't allow one user to crash the system by a low safety declaration.
15:48:18
beach
I might provide some special system privilege to allow the compilation of unsafe code, and I probably will one day.
15:48:57
nyef
("You said this is a FIXNUM. Therefore, it is a FIXNUM. And if anyone (yourself included) passes a non-FIXNUM here, a TYPE-ERROR will be signalled.")
15:49:43
beach
The passage about unsafe code is that it may be run in a separate address space, but that won't work without using stuff like file descriptors, so a program would have to be written to take that into account.
15:50:39
beach
I will use such declarations to prune the possible paths that the type inferencer has to consider.
15:51:09
nyef
This also leaves the door open to "you said this is a FIXNUM, and I can show that this *is* a FIXNUM, so there's no need to check again."
15:52:28
nyef
Hrm. "Thread-safe" breakpoints by abusing per-thread copy-on-write mappings for code pages?
15:53:21
nyef
Requires the ability to have per-thread address space mappings, including as overlays, which isn't AFAIK a feature in many (any?) common OSes, but is definitely an angle.
15:55:03
beach
Clordane requires per-thread breakpoints, so that (say) the debugger can debug the debugger by setting breakpoints in it.
15:56:13
beach
... and so that one can set breakpoints in system functions that are not inlined, without running the risk that the debugger will stop when it hits one of those.
15:56:30
nyef
Another aspect to this, though, is that if the GC is permitted to move code segments, then it needs to migrate the per-thread pages as well.
15:57:34
beach
Though I have been thinking about GC in SICL, and I think I have come to a radical conclusion...
15:58:19
beach
The per-thread GC is a sliding (compacting) collector, but my recent thinking is to make the global GC is won't move its objects.
15:59:56
nyef
The main disadvantage that immediately comes to mind is the potential for weird heap fragmentation issues.