log
49 entries in 0.327s
feedbot: http://thetarpit.org/posts/y05/093-hunchentoot-i.html << The Tar Pit -- A review of Hunchentoot's code history
a111: Logged on 2019-05-30 18:45 phf: http://btcbase.org/log/2019-05-29#1916136 << i'm using hunchentoot-1.2.35 but that's in no way explored, that's whatever i got out of quicklisp on first btcbase deploy
phf: i'm not sure that's particularly useful. at the time i was still switching between running btcbase on hunchentoot in prod and on alisp/aserve in development
phf: i'm also using http://marijnhaverbeke.nl/talks/defservice/ in front of it, and i added support for hunchentoot, so i rarely write anything that looks like hunchentoot specific code.
phf: http://btcbase.org/log/2019-05-29#1916136 << i'm using hunchentoot-1.2.35 but that's in no way explored, that's whatever i got out of quicklisp on first btcbase deploy ☝︎☟︎
spyked: so far I've been looking at the project changelog and the patch history and the patches seem like a mixed bunch, with (perhaps) some useful things and breakage a la sslism. so before going further, I'd like to get some idea of what version of hunchentoot the lordship and the L2 are using
a111: Logged on 2019-05-22 21:36 lobbes: http://www.thetarpit.org/posts/y05/090-tmsr-work-ii.html#selection-197.31-205.258 << I wager there's a good chance you'll publish a genesis of tbnl/hunchentoot before I eat through mod_lisp, but I agree: as pieces emerge, we can sync up, regrind as needed, etc.
spyked: good morning, #t! following up on the http://btcbase.org/log/2019-05-22#1915244 thread: I've started reviewing hunchentoot, the first step would be to figure out which code base to use as a starting point from the genesis. ☝︎
lobbes: http://www.thetarpit.org/posts/y05/090-tmsr-work-ii.html#selection-197.31-205.258 << I wager there's a good chance you'll publish a genesis of tbnl/hunchentoot before I eat through mod_lisp, but I agree: as pieces emerge, we can sync up, regrind as needed, etc. ☟︎
spyked: mp_en_viaje, should take less than that, giving myself time to work through potential unexpected issues, e.g. it's been a while since last time I used hunchentoot, need to reload it in head.
a111: Logged on 2019-05-06 15:00 phf: mp_en_viaje: it's the shitsoup ecosystem, there's a handful of packages smartly written, like hunchentoot or cl-http, and then there's new wave of cffi-everything approaches, that stand tall and pretend to be people
spyked: http://btcbase.org/log/2019-05-06#1911562 <-- I will give hunchentoot a second look as well, in light of http://btcbase.org/log/2019-05-06#1911437 ☝︎☝︎
a111: Logged on 2019-05-06 15:01 phf: tbnl from which hunchentoot comes used to be pure mod_lisp, another code to look at
a111: Logged on 2019-05-06 15:00 phf: mp_en_viaje: it's the shitsoup ecosystem, there's a handful of packages smartly written, like hunchentoot or cl-http, and then there's new wave of cffi-everything approaches, that stand tall and pretend to be people
phf: tbnl from which hunchentoot comes used to be pure mod_lisp, another code to look at ☟︎
asciilifeform: 'hunchentoot' etc. are almost always run 'behind' apache as it is ( so static files serve up faster )
phf: mp_en_viaje: it's the shitsoup ecosystem, there's a handful of packages smartly written, like hunchentoot or cl-http, and then there's new wave of cffi-everything approaches, that stand tall and pretend to be people ☟︎☟︎
a111: Logged on 2019-05-06 09:23 spyked: http://btcbase.org/log/2019-05-02#1910755 <-- I dun much like hunchentoot, on account of http://thetarpit.org/posts/y03/05c-development-log-i.html#selection-187.0-192.0 ; but I'm open to using it if the alternatives turn out to be insufficient
asciilifeform: http://btcbase.org/log/2019-05-06#1911347 << last time i surveyed the available items (~decade ago) 'hunchentoot' turned out to be the only 1 that wasn't fatally defective in some obvious way (some of the alternatives wouldn't build at all, others -- wouldn't use iron threads on x86; yet others missing some large piece , e.g. custom eggog pgs , etc ) but it's been a while ☝︎
phf: spyked: wookie is not a hunchentoot fork, it's its own thing built around an async ffi. one thing you might want to add to your list is how much ffi-ing is required, or rather how "c heavy" the code is. for example teepeedee2 is extremely fast, but doesn't work anywhere but sbcl and linux, because it uses all kinds of libc features.
a111: Logged on 2019-05-02 14:35 lobbes: though it seems like lots of people here use hunchentoot for that purpose, and it seems that hunchentoot is easily modified to interface with apache through mod_lisp
spyked: http://btcbase.org/log/2019-05-02#1910755 <-- I dun much like hunchentoot, on account of http://thetarpit.org/posts/y03/05c-development-log-i.html#selection-187.0-192.0 ; but I'm open to using it if the alternatives turn out to be insufficient ☝︎☟︎
lobbes: though it seems like lots of people here use hunchentoot for that purpose, and it seems that hunchentoot is easily modified to interface with apache through mod_lisp ☟︎
asciilifeform: you don't miss cgi in hunchentoot.
asciilifeform: trinque: that's exactly the kind of thing i wouldn't do. my hypothetical http serv would be strictly for fully adatronic app. like hunchentoot in cl world.
phf: amusingly none of that "super fast" shit is used anywhere. venerable hunchentoot was used used by weitz to deliver consulting solutions (was also used by me for same purpose back when it was tbnl), these super fast toys are used to host author's blog.
phf: ben_vulpes: are you using hunchentoot?
trinque: haha, but hey sbcl is threaded and hunchentoot exists.
phf: re cmucl threads i think that it doesn't always preempt correctly. like it has explicit yield, which you don't always have to call, but it being there implies. also hunchentoot wasn't working right without putting a yield somewhere in the scheduler. it's all very vague, because i've not spend any time looking at it
ben_vulpes: (hunchentoot uber alles)
phf: ben_vulpes: actually right now i'm heathen-ing it, by using quicklisp too. problem is btcbase depends on 35 different projects (like hunchentoot pulls 8 deps, cl-irc 2, etc.) so cmucl version i had all 35 hand patched to various degrees. the right way seems to be giving all those project the v treatment: pull them in, strip them of fluff, genesis, etc.
asciilifeform: http://weitz.de/hunchentoot
asciilifeform: afaik the lisp folks here are all using hunchentoot
trinque: plenty of lisp tools there too; I've used hunchentoot plenty
phf: (a much harder task in hunchentoot)
phf: well, to be fair it's not very good, but it hosted cliki for 10 years, easier to hack on than hunchentoot on account of having simpler design and i'm trying to make it sling byte arrays
trinque: hunchentoot uber alles
trinque: hunchentoot is good
asciilifeform: e.g., in a few years a n00b looking for 'web server' will find ten qeergendered flycheckesque atrocities and - if he is very very lucky - one 'hunchentoot' in a state of disrepair
assbot: Logged on 06-01-2016 04:07:24; phf: asciilifeform, ben_vulpes, adlai: edi weitz (cl-ppcre, hunchentoot, flexi-streams rest of ediware) published a book of common lisp recipes http://www.amazon.com/o/asin/1484211774
assbot: Logged on 06-01-2016 04:07:24; phf: asciilifeform, ben_vulpes, adlai: edi weitz (cl-ppcre, hunchentoot, flexi-streams rest of ediware) published a book of common lisp recipes http://www.amazon.com/o/asin/1484211774
phf: asciilifeform, ben_vulpes, adlai: edi weitz (cl-ppcre, hunchentoot, flexi-streams rest of ediware) published a book of common lisp recipes http://www.amazon.com/o/asin/1484211774 ☟︎☟︎
assbot: Logged on 26-07-2015 22:16:44; ben_vulpes: the "async" cl webserver the nodebros are banging on about blocks the repl when instantiated in a cl-async 'event loop', unlike how hunchentoot starts a server and then returns on threaded sbcl.
ben_vulpes: the "async" cl webserver the nodebros are banging on about blocks the repl when instantiated in a cl-async 'event loop', unlike how hunchentoot starts a server and then returns on threaded sbcl. ☟︎
ben_vulpes: anyways i was poking at hunchentoot in service of making an httoy out of some of the patches that you've posted recently and discovered that the sbcl i had on the plane didn't support threads
gabriel_laddel: trinque: are you just playing around with hunchentoot, or writing a production system?
trinque: it's somewhat interesting to note that wikipedia has a german page on hunchentoot, but the english one was deleted.
asciilifeform: trinque: even hunchentoot. the www stack is fundamentally retarded
trinque: even hunchentoot?