freenode/#sicl - IRC Chatlog
Search
10:23:37
beach
It is interesting to contemplate what the equivalent of a web browser would be in the context of CLOSOS.
10:23:42
beach
To begin with, I think there would be independent "modules" or "programs" for each kind of rendering engine; one for HTML, one for each type of image format, one for each type of video format, one for each type of sound format, etc.
10:23:44
beach
Then I think there would be a general-purpose "window manager" that would organize windows into bigger ones, into tabs, into "frames", etc. So there would be no concept of a "web browser" other than the collection of the individual rendering modules and a general window manager that would be used for other things as well.
10:24:27
beach
Now, I haven't thought about this very much, so I may very well have missed something.
10:25:10
beach
But if I am even kind of right, then we should not set out to write a web browser, but instead to write those modules for rendering various kind of multimedia contents.
10:26:49
Shinmera
browsers become large not really due to their UI or necessarily the media content, but rather because rendering HTML and running JS is such a gargantuan task nowadays
10:28:07
beach
Well, I wasn't thinking of size. Just of the way the code for such a thing would be organized.
10:29:58
beach
I remember what Rob Pike wrote on those slides that were referred to here, namely that when Plan 9 was written, some significant fraction of the effort was spent on implementing standards. I think that fraction may be even higher now.
11:01:37
no-defun-allowed
One of the issues that web browsers is minimising latency, which requires good concurrency and incremental parsing.
11:02:23
no-defun-allowed
(HTTP and HTML are huge standards, too, you can find something new in the Mozilla developer wiki every time you look.)
11:03:01
no-defun-allowed
For example, in HTML, one doesn't define columns and rows or layout like in a system like CLIM. The developer makes some nested "boxes" and uses a second CSS file to define a layout.
11:04:05
no-defun-allowed
But, you probably know that, since I assume you created the pages on metamodular.com. The difficulty arises in loading new content as the parser reads cues for it to load. Incremental rendering is also a related problem.
11:06:05
beach
Though continuous rendering often drives me crazy. I look at the page for the weather forecast, click on a day, but before the click takes effect, some add has been rendered where I clicked, instead.
11:07:52
no-defun-allowed
uBlock Origin is reliable and runs on Firefox and Chrome, if you need pointers.
11:08:59
no-defun-allowed
You can also set how aggressive the blocker is, as several lists of ad and malware groups are provided that cover different things to avoid.
11:11:22
no-defun-allowed
When sites are really terrible, I find noscript (disabled by default, which is not how it was intended to be used) a good "to hell with this site" tool too. It usually works with news paywalls and guitar tabulature sites that disable copying. Noscript is a very extreme option though.
11:15:08
no-defun-allowed
(A silly almost-conspiracy theory a friend and I had was that web standards were intentionally hard to implement so there would be an oglipoly on web browsers. It's probably just accumulation of implementation specific extensions though.)
11:15:42
Shinmera
Funny about that, the IEEE spec for floats was actually intentionally made harder by Intel to slow down competitors
11:16:58
beach
So maybe if we decide to start a project for rendering HTML, we need to make sure it is highly modular to begin with, so that it can be worked on in parallel by several people.
11:18:19
no-defun-allowed
There are also niche things like anti-anti-adblock tools, which try to stop sites that run JavaScript to detect adblockers and trash the site.
11:19:22
no-defun-allowed
"trashing" as in removing all content from the site and replacing it with a dialog requesting you disable your adblocker.
11:19:49
no-defun-allowed
shka_: We've been discussing the complexity of a web browser/renderer for a while.
11:22:04
no-defun-allowed
In an old Visual BASIC book I have, there is a guide for writing a web browser, but it is a shell over the Internet Explorer renderer. A HTML renderer would be a good selling point for CLIM, but I could imagine it backfiring and people developing in HTML as they do with Electron.
11:22:21
no-defun-allowed
Even sadder is that the expectation for operating systems is to run web browsers.
11:27:14
beach
no-defun-allowed: So you can start a project to create a highly modular HTML renderer, and then solicit people to help you with each module.
11:28:15
no-defun-allowed
Mind you, Rust only came along and got big because Mozilla wanted a safer C++, so it's quite a self fulfilling prophecy "that Rust is good because it is good for browsers".
11:30:42
no-defun-allowed
I'm not sure how to structure a HTML browser. I wrote a silly proof of concept which just dumped text nodes in the document, but otherwise it's a black box to me.
11:32:56
jackdaniel
writing a web browser requires a few things: html renderer, dom inspector, javascript compiler and css parser (not necessarily in this order), plus everything what comes around the webrowser (address bar, bookmarks and such)
11:33:15
jackdaniel
there is / was a project "closure" aiming at being a web browser, it is abandonware afaik
11:33:41
jackdaniel
writing things "around the browser" is a pretty big thing on its own terms, many web browser use existing engines
11:34:41
beach
jackdaniel: My initial suggestion was to abandon the entire idea of a web browser and work on individual rendering modules instead.
11:35:31
no-defun-allowed
As far as I can tell, HTML conflicts quite a bit with how most graphical toolkits work. HTML just has boxes, but toolkits like grids, rows and columns. I'm not sure how you would attach a renderer without a lot of reimplementation of the graphical toolkit.
11:37:43
beach
jackdaniel: Everything except the GUI, the menus, the tabs, etc. Individual modules for rendering sound, images, video, etc.
11:37:47
no-defun-allowed
"oh god no-defun-allowed that pun was awful the author of plump is in the room too"
11:38:31
Shinmera
It parses /correct/ HTML according to spec but does not when it's incorrect, which is the hard part about HTML5
11:39:06
beach
jackdaniel: For what it's worth, I am totally uneducated in this domain as well. I am just trying to give some useful project to no-defun-allowed. :)
11:39:48
Shinmera
Easier, useful projects would be to add tests and documentation to existing projects
11:41:24
jackdaniel
working on js compiler in common lisp would be a good step towards having cl webbrowser engine
11:42:10
no-defun-allowed
Yes, I think I just need to read over cursors now. The storage mechanics make sense now.
11:45:41
no-defun-allowed
It's so simple I was able to explain it to my father with a visual analogy.
14:11:26
Bike
i want to be clear on something. the dynamic environment is not closed over with how sicl works right now. all that's closed over is a marker for a particular entry- the timestamp or something like it. the rest of the dynamic environment would be pointless to close over.
14:12:40
beach
But I consider that (the timestamp, etc) to be an implementation strategy to avoid heap allocation of the full dynamic environment entries.
14:13:30
beach
Morally speaking, the dynamic environment is closed over when you have (block b (f (lambda () (return-from b))))
14:14:39
Bike
the other thing is that even if an implementation does choose to be weird and do that, it would be the "continuation" output from catch, which already exists. the "dynamic-environment" variable/output itself wouldn't be closed over.
14:16:36
beach
Hold on. I don't see a difference between the "continuation" output from catch and the dynamic environment variable.
14:20:49
beach
Suppose we abandon the explicit time stamp in HIR. Do we have reasons to believe that with only the dynamic-environment variables, we can't implement the timestamp strategy?
14:21:42
Bike
That would be kind of weird. We'd have this one output from catch, and we'd use it both in local calls (as the full dynamic environment) and in nonlocal unwinds to the catch (as the timestamp), so the one output would have different values depending on context.
14:24:09
beach
The way I see it is that in HIR, there would be no mention of time stamps. In fact, I may change the strategy in SICL and just heap allocate the entire entry, rather than just the time stamp. There is not much to gain from only allocating the time stamp on the heap.
14:26:24
Bike
Why is it silly to read from a closure cell for literally every call, to get at a value that could not only be local, but stack-allocated, if the compiler was organized differently?
14:27:39
beach
The dynamic environment should not be closed over and then escape arbitrarily. That is explicitly ruled out by the standard.
14:28:51
beach
Many implementation currently do not catch the problem and let the application use an exit point anyway, even if it has been abandoned.
14:29:22
beach
It is fair to say that it should be extremely rare for such capture+escape to happen, since it is incorrect behavior.
14:30:04
beach
So, suppose we do not mention time stamps explicitly in HIR and just use the full dynamic environment.
14:30:26
beach
In almost all cases, the compiler can detect that this dynamic environment has dynamic extent.
14:31:15
beach
Even in the case (block b (f (lambda () (return-from b)))), usually F is known not to hold on to the closure.
14:31:48
beach
And in fact, this becomes the same problem as detecting other things that might have dynamic extent.
14:32:18
Bike
In fact relying on that goes against the whole premise that the user should be able to redefine f without breaking things.
14:32:56
beach
Most function aren't, but then most of the time, no such closure will be passed to a function either.
14:33:28
beach
so, the number of cases where you have an unknown function being called with a closure that happens to capture the dynamic environment is likely to be vanishingly small.
14:33:56
Bike
It happens all the time! Even within cleavir! The map over AST and IR functions, off the top of my head
14:35:00
Bike
You're talking about breaking something we already have working, that doesn't even take any special casing, for the sake of optimizations we don't have and possibly can't have.
14:37:26
Bike
If we have (f (lambda () (return))), all we conceptually need to close over is the reference to the NIL block. The rest of the dynamic environment at the time the closure is created is irrelevant.
14:40:21
Bike
What happens is that if that function is called after the block has exited, so that the return is now invalid - the unwinding code looks through its dynamic environment - whatever dynenv the lambda was called in - and it doesn't find the block timestamp. So it goes, okay, it's out of extent, i signal an error.
14:42:22
beach
The timestamp think is documented in SICL and not in Cleavir because it is a SICL idea.
14:43:00
beach
I can very well imagine a Cleavir-based compiler for SBCL that would not want to use timestamps at all, because it would interact badly with existing code.
14:43:56
beach
So when you suggested explicit dynamic environments, I thought that was a great abstraction that would work for any implementation.
14:44:54
Bike
yeah. i still think so. they're even fine in clasp which doesn't even have them at runtime.
14:44:57
beach
If in SICL I want to continue using this timestamp idea, I have the impression that I could still do that by treating this new dynamic-environment abstraction as consisting of two parts. One part to be allocated on the stack and one part to be allocated in the static environment.
14:47:00
beach
By abandoning time stamps at the HIR level (I didn't even realize that they had crept in), we could get a uniform treatment of dynamic-extent data.
14:47:45
beach
If there is a call to an unknown function with a closure inside, an implementation (SICL, maybe) would just use the time stamp as usual, and nothing will change.
14:48:52
beach
But it would require that we are convinced that the timestamp implementation can be used in lower levels (MIR?) and derived from a model with no timestamp in HIR, only the full dynamic environment.
14:49:33
Bike
Yeah. I'm not convinced of that. I am in fact convinced of the opposite of that: If we only have explicit dynamic environments, and no individual block references, I don't think we can reasonably separate them again.
14:49:53
Bike
Whereas if we do it like now, where CATCH outputs the two parts, an implementation that does not have explicit block references can just output the same value for both outputs.
14:54:01
Bike
and also the dynamic extent machinery would have to be informed that both outputs rely on the input instead of just one, i guess, but i don't think that will be hard to arrange in the hypothetical world in which we have dynamic extent machinery
15:06:45
beach
I think it would be unfortunate if we forced a timestamp implementation on all clients, but if you think that can be avoided, then that's fine.
15:07:37
Bike
i mean, it didn't "creep in", we discussed this months ago when I was adding catch-instruction - having a nonlocal return-from or go means you have to close over _something_. Cleavir continues to not define the particular nature of that something, as it should be.
15:09:02
Bike
also, once i work this out for clasp i'll take a minute to get it working in the sicl hir backend too, before i push anything to master
15:09:21
Bike
it's a pretty big change so i'll probably try to put it as a pull request or something so you can look it over
16:01:01
jcowan
I have satirized what it would be like to live in a least-privilege world: you wouldn't, for example, have any identifying information about your life partners, since you have no need to know that.
16:03:11
jcowan
they are all about using every possible means to make sure that no program has access to anything it doesn't absolutely require access to.
16:03:39
jcowan
In that context, "kill and restart" is indeed the right approach to recovery from failure.
19:28:52
Bike
i'm going to have generate-ast take an extra ast argument for the dynamic-environment, but leave it optional, so that a semi sane result will still happen for users that don't care (e.g., for things other than compiling)
21:35:10
Bike
okay, next problem: the way call-with-variable-bound is generated screws everything up
21:42:12
Bike
either that or reorient how the parameter processing works. that might be a good idea anyway...