iovec has quit [Quit: Connection closed for inactivity]
varjag has quit [Ping timeout: 250 seconds]
figurehe4d has quit [Remote host closed the connection]
figurehe4d has joined #lisp
_whitelogger has joined #lisp
<lowryder>
sjl: Thanks for the description and the image. That was very kind.
<lowryder>
sjl: It took me a moment, but everything became clear when I tracked down your sbcl-vlime command
pierpal has quit [Ping timeout: 240 seconds]
Kevslinger has quit [Quit: Connection closed for inactivity]
robdog has quit [Ping timeout: 250 seconds]
karlosz has quit [Quit: karlosz]
pierpal has joined #lisp
<margaritamike>
Is lisp a good language for web crawling?
Mr-Potter has quit [Quit: Leaving]
<Xach>
margaritamike: there are probably a lot more libraries to save you work in other environments.
<no-defun-allowed>
it's not too hard to scrape websites with CL libraries
<Xach>
There are libraries to parse html and libraries to fetch web pages in lisp, but not as many choices
<Xach>
If I were doing it, I'd use lisp, because I like lisp!
<Xach>
But possibly not if I was in a very great hurry.
<no-defun-allowed>
writing a scraper in CL would be less time for everyone in the future though
<pjb>
Once upon a time, web crawling involved a lot of ad-hoc coding. For that, lisp was rather good. Nowadays, we may assume that web pages are more correctly following standard, but that's not entirely the case. So depending on the pages and their age, you may find that lisp is preferable than using other libraries that may be harder to patch.
<Xach>
Not my problem! You can't make me work for everyone!
<pjb>
On the other hand, nowadays, you would definitely want a complete javascript implementation to be able to crawl random sites correctly.
<no-defun-allowed>
Xach: you get paid in ego-stroking at least :P
<Xach>
fortunately my bank accepts smiles and kind words for mortgage payments
<Xach>
it is good to make things for everyone. i am only having a little fun.
<no-defun-allowed>
i heard the coffee shop a few blocks away accepts experience for payment
JetJej has joined #lisp
<margaritamike>
pjb: so you're saying lisp would be a bad choice for the task these days?
amerlyq has quit [Quit: amerlyq]
terpri has quit [Remote host closed the connection]
<pjb>
margaritamike: not exactly.
<pjb>
But the advantages of lisp can be its inconvenients; it doesn't have all batteries included. When you need to understand and modify the code, it doesn't matter. But if you just to do something predetermined fast, a canned library might be better.
<pjb>
On the other hand, IME, most of the time when you start with a canned solution, you find that it's defective in a way or another, and you end losing more time trying to make it work to your case than if you had started from scratch with lisp…
dale has quit [Quit: dale]
CCDelivery has joined #lisp
FreeBirdLjj has joined #lisp
<margaritamike>
That feel when the community is mostly defeatist :P
<margaritamike>
The way you folks sound, I'd think lisp is dead
Oladon has joined #lisp
<margaritamike>
I'll keep these things in mind though
<no-defun-allowed>
you can trust pjb to be a saddist, i hope other people here are more optimistic
figurehe4d has quit [Ping timeout: 240 seconds]
aindilis has joined #lisp
<pjb>
For example, once I had to write a simple program for OpenWRT. Instead of using ecl as I would have, I had to do it in python. But on that processor, python didn't support threads, so the core functionality of this program couldn't be implemented. Alternative python compilers were of no use. Eventually, I wrote it in C, but it would have been done in a fraction of the time in CL with ecl.
quazimodo has quit [Ping timeout: 240 seconds]
quazimodo has joined #lisp
libertyprime has joined #lisp
xkapastel has quit [Quit: Connection closed for inactivity]
gxt has quit [Ping timeout: 245 seconds]
gxt has joined #lisp
keep_learning has joined #lisp
Essadon has quit [Quit: Qutting]
keep_learning has quit [Quit: Ping timeout (120 seconds)]
markoong has quit [Read error: Connection reset by peer]
keep_learning has joined #lisp
markoong has joined #lisp
mathpacka has quit [Remote host closed the connection]
moei has joined #lisp
markoong has quit [Quit: Konversation terminated!]
Oladon has quit [Quit: Leaving.]
gxt has quit [Ping timeout: 240 seconds]
<sjl>
lowryder: oh yeah, that command is a good one to show how the thing actually works
<sjl>
sometimes I forget how many layers of yak shaving I've done
karlosz has joined #lisp
dale has joined #lisp
JetJej has quit [Read error: Connection reset by peer]
milanj has quit [Quit: This computer has gone to sleep]
space_otter has joined #lisp
karlosz has quit [Quit: karlosz]
anewuser has joined #lisp
zotan has quit [Ping timeout: 244 seconds]
zotan has joined #lisp
zotan has quit [Ping timeout: 245 seconds]
igemnace has quit [Read error: Connection reset by peer]
FreeBirdLjj has quit [Remote host closed the connection]
zotan has joined #lisp
igemnace has joined #lisp
CCDelivery has quit [Remote host closed the connection]
zotan has quit [Ping timeout: 240 seconds]
zotan has joined #lisp
themsay has quit [Ping timeout: 240 seconds]
marvin2 has quit [Ping timeout: 240 seconds]
<beach>
Good morning everyone!
_whitelogger has joined #lisp
jkordani has quit [Read error: Connection reset by peer]
<aeth>
margaritamike: It's not defeatist. The main drawback of CL is that if 95% of your work is already done in a library, it's probably not a CL one
<aeth>
this is the realistic drawback of any non-top-10 language without a corporate sponser that can pay for replacement libraries
<margaritamike>
Lisp needs a great rejuvenation
<beach>
margaritamike: What action do you have in mind?
ismay has joined #lisp
<margaritamike>
For that to happen, more tools need to be made even if they exist in Python
figurehe4d has quit [Remote host closed the connection]
rippa has joined #lisp
FreeBirdLjj has joined #lisp
FreeBirdLjj has quit [Ping timeout: 250 seconds]
moei has quit [Ping timeout: 268 seconds]
libertyprime has quit [Read error: Connection reset by peer]
libertyprime has joined #lisp
X-Scale has quit [Read error: Connection reset by peer]
sauvin has joined #lisp
dddddd has quit [Remote host closed the connection]
prite has joined #lisp
prite has quit [Ping timeout: 268 seconds]
jerme_ has left #lisp [#lisp]
Bike has quit [Quit: Lost terminal]
meepdeew has joined #lisp
nanoz has joined #lisp
FreeBirdLjj has joined #lisp
ldb has joined #lisp
<ldb>
good eve
<beach>
Hello ldb.
karlosz has joined #lisp
pritambaral has joined #lisp
ldb has quit [Ping timeout: 245 seconds]
q-u-a-n has quit [Read error: Connection reset by peer]
FreeBirdLjj has quit [Ping timeout: 240 seconds]
FreeBirdLjj has joined #lisp
FreeBird_ has joined #lisp
<phoe>
ldb
<phoe>
this name brings back memories
FreeBirdLjj has quit [Ping timeout: 250 seconds]
FreeBird_ has quit [Read error: Connection reset by peer]
FreeBirdLjj has joined #lisp
dale has quit [Quit: dale]
<no-defun-allowed>
[angry SBCL user noises]
abhixec has quit [Ping timeout: 240 seconds]
<no-defun-allowed>
or, alternatively, [bit shifting PDP-10 user noises]
<verisimilitude>
We think alike, margaritamike.
<verisimilitude>
I've been writing scraping tools for a very particular type of website lately; it's not in a finished and packaged state, though.
<verisimilitude>
I was using a special patch of DRAKMA for HTTP requests, but I've not yet written code to resume interrupted downloads and other such things; it worked well enough, though.
pritambaral has quit [Ping timeout: 268 seconds]
<verisimilitude>
I had a HDD failure, however, and so I'm currently just having my Lisp write out files for GNU wget to process, instead.
<verisimilitude>
I noticed CL-JSON was absurdly slow when processing hundreds of thousands of records, so I've been very lightly working on my own JSON library. I call it JSON-SUCKER, because that implies JSON sucks.
<no-defun-allowed>
lol
quazimodo has quit [Ping timeout: 250 seconds]
pvaneynd has joined #lisp
ravenousmoose has joined #lisp
igemnace has quit [Ping timeout: 245 seconds]
ismay has quit [Ping timeout: 246 seconds]
pvaneynd has quit [Ping timeout: 246 seconds]
_whitelogger has joined #lisp
igemnace has joined #lisp
libertyprime has quit [Remote host closed the connection]
wigust has quit [Read error: Connection reset by peer]
robdog has joined #lisp
ravenousmoose has quit [Quit: Taking a quick nap...ZZzzz]
<phoe>
Jachy: depends on whether the existing ones do the job
<verisimilitude>
I didn't bother looking much, but I believe my approach will be unique.
<jackdaniel>
jsown is very performant, yason is very feature complete
<phoe>
if performance of the existing ones is not satisfying, it might be worth to try again
<phoe>
jackdaniel: TIL, thanks
<phoe>
verisimilitude: have you tried it?
<verisimilitude>
I'm going to offer the ability to work directly on the string contents of the JSON, rather than trying to make an efficient parser.
<jackdaniel>
as of NIH syndrome, I can't say it is reassuring given how many projects which already exist need more people
ravenousmoose has quit [Quit: Taking a quick nap...ZZzzz]
<jackdaniel>
(especially without proper state of the art research)
<verisimilitude>
This library was thought of because I'd replaced the slow CL-JSON with a simple and efficient string operation; I figured if I could get most of the way there with this approach, generalized, I'd just use it.
wigust has joined #lisp
<phoe>
verisimilitude: have you tried other existing libraries though?
<verisimilitude>
I've tried CL-JSON; that's all.
<phoe>
your approach sounds like NIHS then.
<verisimilitude>
Common Lisp is a language that lets me avoid working with others, which is what I prefer to do.
<phoe>
okiedokie
<otwieracz>
Oh, another JSON library?
<otwieracz>
:]
<jackdaniel>
hue
<verisimilitude>
Besides, I don't have any other Common Lisp libraries I could be working on, at the moment, sans one that should be rather small.
<verisimilitude>
Well, that's not true; I've been meaning to start on Gopher software in Common Lisp.
wigust has quit [Ping timeout: 240 seconds]
<jackdaniel>
knusbaum written a gopher client in clim some time ago
<jackdaniel>
to be more precise: he wrote a "normal" client and worked on CLIM gui for it
<makomo>
i really like the comparisons sabraonthehill does, very nice
<jackdaniel>
and first thing to consolidate them he declared many maintained libraries "obsolete" in favour of his own uiop thing, I don't think it is the nicest of ways to invite contributors
<beach>
Heh.
<verisimilitude>
No, that sounds about right, jackdaniel.
<jackdaniel>
either way I don't find this approach nice nor acceptable
<verisimilitude>
Oh, before I read this, let me guess: MIT good, GPL bad!
akoana has left #lisp ["Leaving"]
<phoe>
verisimilitude: nope
<jackdaniel>
not really
<phoe>
it doesn't even mention licensing
<Jachy>
On the flip side, "Once on #haskell, I was asked why I have no large programs to my credit; I replied, 'My problem is that most programs I use already exist.'" Some NIH is acceptable to me.
<phoe>
and the only occurrence of "mit" in the text is in the word "dammit"
<verisimilitude>
Well, that's surprising, then.
<phoe>
only if your expectations involved licensing in the first place
<verisimilitude>
It's usually a common thread.
<phoe>
I have had different experiences
mrcom has quit [Ping timeout: 272 seconds]
<verisimilitude>
Well, that's interesting.
FreeBirdLjj has quit [Remote host closed the connection]
igemnace has quit [Remote host closed the connection]
karlosz has quit [Quit: karlosz]
scymtym has quit [Ping timeout: 246 seconds]
wigust has joined #lisp
space_otter has quit [Remote host closed the connection]
shka_ has joined #lisp
nanoz has quit [Ping timeout: 250 seconds]
igemnace has joined #lisp
FreeBirdLjj has joined #lisp
varjag has joined #lisp
moei has joined #lisp
frodef has joined #lisp
nanoz has joined #lisp
<MichaelRaskin>
Re: scraping and JS — well, I do have my code for driving a sandboxed Firefox via Marionette online.
<MichaelRaskin>
(And then again I prefer to use CL-HTML5 + CSS-Selectors and some custom code to export to text in a way I like it…)
<MichaelRaskin>
Fare can realistically demand an exception re: other libraries, because ASDF needs to do a lot of things, and having a ton of dependencies for ASDF is somewhat inconvenient… But yes, this does undermine credibility of an effort for greater unification.
FreeBirdLjj has quit [Read error: Connection reset by peer]
josemanuel has joined #lisp
holycow has joined #lisp
FreeBirdLjj has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
frodef has quit [Ping timeout: 250 seconds]
ismay has joined #lisp
random-nick has joined #lisp
nanoz has quit [Ping timeout: 246 seconds]
mrcom has joined #lisp
milanj has joined #lisp
igemnace has quit [Quit: WeeChat 2.3]
meepdeew has quit [Remote host closed the connection]
Zaab1t has joined #lisp
quazimodo has joined #lisp
JetJej has joined #lisp
dddddd has joined #lisp
FreeBirdLjj has joined #lisp
iovec has joined #lisp
terpri has joined #lisp
Lord_of_Life_ has joined #lisp
devon has joined #lisp
Lord_of_Life has quit [Ping timeout: 240 seconds]
Lord_of_Life_ is now known as Lord_of_Life
FreeBirdLjj has quit [Ping timeout: 240 seconds]
scymtym has joined #lisp
metallicus has joined #lisp
ravenousmoose has joined #lisp
devon has quit [Ping timeout: 240 seconds]
quazimodo has quit [Ping timeout: 240 seconds]
dddddd has quit [Ping timeout: 250 seconds]
dddddd has joined #lisp
themsay has joined #lisp
devon has joined #lisp
ravenousmoose has quit [Quit: Taking a quick nap...ZZzzz]
robdog has quit [Remote host closed the connection]
markoong has joined #lisp
anewuser has quit [Quit: anewuser]
emar has quit [Ping timeout: 252 seconds]
wxie has joined #lisp
themsay has quit [Ping timeout: 240 seconds]
themsay has joined #lisp
makomo has quit [Ping timeout: 246 seconds]
wxie has quit [Ping timeout: 240 seconds]
robdog has joined #lisp
orivej has quit [Ping timeout: 240 seconds]
Essadon has joined #lisp
paule32 has quit [Ping timeout: 244 seconds]
Essadon has quit [Max SendQ exceeded]
Essadon has joined #lisp
wxie has joined #lisp
nanoz has joined #lisp
nowhereman has joined #lisp
scymtym has quit [Ping timeout: 240 seconds]
FreeBirdLjj has joined #lisp
milanj has quit [Ping timeout: 240 seconds]
Josh_2 has joined #lisp
Josh_2 has quit [Read error: Connection reset by peer]
Josh_2 has joined #lisp
Josh_2 has quit [Read error: Connection reset by peer]
Josh_2 has joined #lisp
Josh_2 has quit [Read error: Connection reset by peer]
Josh_2 has joined #lisp
Josh_2 has quit [Client Quit]
metallicus has quit [Quit: WeeChat 2.3]
Josh_2 has joined #lisp
wxie has quit [Ping timeout: 240 seconds]
scymtym has joined #lisp
robdog has quit [Remote host closed the connection]
makomo has joined #lisp
Bike has joined #lisp
<pjb>
the fact is, if you have to go to Mars or farther, what programming language should you bring with you? stackoverflow will be at more than 1/2 hour away for Mars, days, or years away if you go farther!
Zaabtop has joined #lisp
<pjb>
Will you bring a language for which armies of programmers are needed to develop libraries or give you help to write each line, or will you bring a language in which YOU CAN write everything yourself.
<pjb>
Yeah, no question mark. You will take lisp!
<pjb>
Common Lisp, the programming language for the stars!
Zaab1t has quit [Ping timeout: 250 seconds]
Zaabtop is now known as Zaab1t
<shka_>
pjb: cool story
gxt has joined #lisp
<devon>
Aeons ago, a friend parodied Dijkstra "My graduate students vill profe a theorem und I vill publish a paper ... but we've no help for the poor slobs in the trenches who minimize head motion to optimize seek time."
<pjb>
Well, that's not a good parody, because Dijkstra would have had no problem designing an algorithm proven to be the best to optimize seek times.
<pjb>
You would still have to implement it and test it, however…
FreeBirdLjj has quit [Read error: Connection reset by peer]
orivej has joined #lisp
beach has quit [Ping timeout: 252 seconds]
iovec has quit [Quit: Connection closed for inactivity]
devon has quit [Ping timeout: 268 seconds]
beach has joined #lisp
pvaneynd has quit [Ping timeout: 252 seconds]
ravenousmoose has joined #lisp
svillemot has quit [Ping timeout: 250 seconds]
frodef has joined #lisp
pvaneynd has joined #lisp
jason_m has joined #lisp
ravenousmoose has quit [Quit: Taking a quick nap...ZZzzz]
orivej has quit [Ping timeout: 268 seconds]
Oladon has joined #lisp
ismay has quit [Ping timeout: 240 seconds]
igemnace has joined #lisp
emar has joined #lisp
orivej has joined #lisp
shifty has quit [Ping timeout: 240 seconds]
devon has joined #lisp
orivej has quit [Ping timeout: 240 seconds]
devon has quit [Ping timeout: 250 seconds]
iovec has joined #lisp
ntbre has joined #lisp
holycow has quit [Quit: leaving]
nowhereman has quit [Remote host closed the connection]
nowhereman has joined #lisp
gxt has quit [Quit: WeeChat 2.3]
undiscovered has joined #lisp
Bike has quit [Quit: Lost terminal]
Zaab1t has quit [Read error: Connection reset by peer]
Oladon has quit [Quit: Leaving.]
scymtym has quit [Remote host closed the connection]
Zaab1t has joined #lisp
scymtym has joined #lisp
verisimilitude has quit [Remote host closed the connection]
cage_ has quit [Remote host closed the connection]
<drewc>
Time is still a big issue for development. My clients have offices in Vancouver, Calgary, Toronto, Montreal, Halifax, and report to London, England. There are reports that want "days". Ok... days where exactly?
<drewc>
Postmodern has SIMPLE-DATE: http://marijnhaverbeke.nl/postmodern/ . I use that as well, along with local-time, and some other hacks, to try and give what they need.
verisimilitude has joined #lisp
themsay has quit [Ping timeout: 245 seconds]
shka_ has quit [Remote host closed the connection]
shka_ has joined #lisp
random-nick has quit [Read error: Connection reset by peer]
cantstanya has quit [Ping timeout: 256 seconds]
Mr-Potter has joined #lisp
cantstanya has joined #lisp
karlosz has joined #lisp
karlosz has quit [Client Quit]
random-nick has joined #lisp
Oladon has joined #lisp
ntbre has quit [Quit: ntbre]
<verisimilitude>
Time is awful.
<verisimilitude>
I prefer to separate it between what I call ``historical time'', which is measuring time based on regular occurences such as the rotation of the Earth, including leap seconds and all of that crap, and then have just ``time'' for what should be an objective measurement of seconds.
<verisimilitude>
Base sixty has some nice factors, though, so if we ever reach Star Trek levels of time management, I'd think just extending sixty seconds, sixty minutes, further would be best.
<verisimilitude>
If you get 60^3, that's just under three days; 60^4 is 150 days; 60^5 is 9,000 days; it works rather nicely, actually.
<verisimilitude>
That's treating a day as (* 24 60 60) as 86,400 seconds.
<verisimilitude>
That 60^5 unit splits a human life rather well; you'd only live three or four of them, if that.
<Younder>
why this obsession with 60? You are not a sumerian..
<verisimilitude>
It works nicely, Younder.
<verisimilitude>
It's better than what we currently use, certainly.
<verisimilitude>
It disgusts me that figuring how many seconds old I am, to any reasonable accuracy, requires searching through historical records to see when the idiots decided to add leap seconds here and there and other nonsense.
<LdBeth>
Well, unsigned integer
<verisimilitude>
If you wanted to create a program that actually traverses the history of the world, as a knowledge base, you'd need to see when a week was subtracted there, and so on and so forth and it's hideously complicated.
frodef has joined #lisp
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
<pjb>
verisimilitude: not counting the international flights you made, which means your proper time got desynchronized with that of Earth!
<verisimilitude>
Don't worry, pjb. I've been in the same timezone this entire time.
<verisimilitude>
I didn't even think of that, though, although probably because I didn't need to.
Josh_2 has quit [Remote host closed the connection]
<pjb>
Then you have to take into account the altitude you lived at!
<verisimilitude>
See, hideously complicated. I'm usually against changing things just because programming in relation to them is difficult, but time is a mess every which way.
<verisimilitude>
There's no great human experience to be had by it being this absurd.
<aeth>
verisimilitude: Base 12 has most of the advantages. Base 60 is just 12*5 for some compatibility with our base 10 (2 * 5) world. The advantages of divisibility (12 items can be divided evenly many ways, while 10 can only be divided evenly into 2*5 or 5*2) are probably not that good now that we live in a digital world. Base 16 would be the way to go IMO.
<jackdaniel>
luckily for us software is made for real world issues, not for programmers convenience. I doubt computers would be so popular otherwise
<aeth>
If we had to have a from-scratch number system it would either be base 12 for better dividing, or base 16 (or base 8) for better digital compatibility, though.
makomo has quit [Quit: WeeChat 2.2]
<verisimilitude>
I'd use base thirty, aeth.
<verisimilitude>
I took the first three primes, two, three, and five, and multiplied them; then you can easily work in halves or thirds or fifths.
<verisimilitude>
This is also reasonable for a person to learn, since it's still comparable to a normal alphabet.
<aeth>
30 = 2 * 3 * 5; 12 = 2 * 2 * 3; 8 = 2 * 2 * 2. If you just care about splitting things up, 8 or 12 are simpler because they're smaller. No one would care about fifths if we didn't have base 10
<pjb>
Sell them 13 to the 11!
<verisimilitude>
Thirty is also a longer number, so you compact information better, aeth.
<pjb>
Invoice only in prime numbers!
<aeth>
12 gives you 4ths which are arguably more important than 5ths. You get halves, thirds, and fourths with 12, you only get halves, thirds, and fifths with 30
<aeth>
60 gives you the most desirable splitting, but it's too large for humans to normally work with as digits
<pjb>
base thirty or sixty are useless to help you with 2431(dec).
<verisimilitude>
Really, I'd say base sixty, but that seems unreasonable for a person to learn and may get cluttered with easily confused symbols.
<verisimilitude>
Oh, we agree on that, then.
<aeth>
60 gives you everything important except 7, 8, and 9.
<aeth>
That's probably why it's useful in time, but not as a digit system.
<aeth>
You can slice an hour many ways.
<verisimilitude>
Base sixty would be the ideal, yes. I'd learn it.
<aeth>
Oh, and I said 60 doesn't give you 8 but half a minute is a nice, neat division so you can still divide your hour (or other time unit) up into 8
<verisimilitude>
A base that's a power of two isn't good for thirds, which I'd think is too much to give up.
ebrasca has joined #lisp
<aeth>
The advantage of using octal or hexadecimal is that all of the counterintuitive properties of floating point go away, and the world is increasingly a binary floating point world, with no sign of mainstream decimal floating point support in sight.
<verisimilitude>
Ultimately, I think it should become a common skill for people to work in many number bases; people are mostly just accustomed to ten and only sixty for time.
<verisimilitude>
Then you can have whatever suits the situation.
<aeth>
Using a base 2 number system, floating point is (afaik) basically just scientific notation with truncation or rounding in places.
<aeth>
(or base 2^n)
<verisimilitude>
You'll only take decimal from me when I'm dead.
<aeth>
If my mind was ever uploaded into a computer, and I'm probably born too early for that, I suspect hexadecimal would be more natural to use, at least if my mind got augmented by the technology instead of merely being replicated.
Inline has quit [Read error: Connection reset by peer]
<verisimilitude>
Let's segue into a Lisp topic; I'm disappointed with using BIT as a stream element type.
<verisimilitude>
SBCL just ignores every octet that isn't zero or one, which isn't the behavior I wanted.
<aeth>
verisimilitude: Technically speaking, we're just debating over which *print-base* and *read-base* to use so it's roughly on topic
<aeth>
Many early Lisps probably had 8 there, not 10
<verisimilitude>
I suppose, but those are limited to base thirty six.
<aeth>
that only excludes 60 from consideration, though
<verisimilitude>
Unfortunately, yes.
<no-defun-allowed>
Yeah, sbcl doesn't pack unsigned-bytes under 8 bits.
<verisimilitude>
So, instead, I'm forced to use (UNSIGNED-BYTE 8) and manually pick it apart, which isn't fun because I'm implementing a format that isn't octet aligned.
<verisimilitude>
Then again, I could be lazy and wasteful and manually create the bit stream myself.
<aeth>
if it's not multiple-of-eight I'd expect pain points somewhere along the way no matter what
<aeth>
Might even be best just to be wasteful and pad it. If you're doing 12, just put 4 0s at the end.
<aeth>
(or start, that's probably better)
josemanuel has quit [Quit: leaving]
<pjb>
verisimilitude: (deftype bit () `(member 0 1))
<verisimilitude>
I like designing numerical formats and I just don't like waste, aeth.
<pjb>
not only should it ignore non-bit value, but it should signal a type error!
<pillton>
versimilitude: According to the Handbook of Floating-Point Arithmetic, the Russian SETUN computer represented numbers in radix 3 which is good for floating point arithmetic.
<verisimilitude>
Yes, the Russian trinary machines were neat.
<pjb>
Once again, only clisp is conforming here: integer 2 is out of range, cannot be output onto #<CLOSED OUTPUT BUFFERED FILE-STREAM (UNSIGNED-BYTE 1) #P"/tmp/bits">
<pjb>
The ENIAC used base 10, which was even better for floating point arithmetic.
<pjb>
No funny stuff like why (/ 5 2) prints out as 2.499999.
<aeth>
verisimilitude: Space vs speed trade-off, it's probably worth it on modern machines to be faster. If you intend to save it to disk or send it over the network, you also can use those bits to ensure that the data is still valid.
<aeth>
It could also be room for future metadata
karlosz has joined #lisp
<verisimilitude>
This works, but my aesthetic sensibilities are violated somewhat:
<verisimilitude>
Wouldn't SBCL store that as octects, pjb?
<pjb>
I don't know at sbcl. I would expect bit by bit. which is what clisp does, apart from a header used to complement the octet file size.
<verisimilitude>
To repeat, SBCL has a nasty habit of simply ignoring any octects that aren't zero or one, in this case. I'm stuck working around (UNSIGNED-BYTE 8), unfortunately.
<pjb>
verisimilitude: yes, it's crazy, abcl, ccl ecl and sbcl write one byte per bit! I strongly advise you to use clisp.
<verisimilitude>
I have CLISP installed, but I'd prefer it work on most anything and (UNSIGNED-BYTE 8) is the LCD for this.
<verisimilitude>
If there were ever an update to the Common Lisp standard, this is just one of the things I'd like to see, proper bit writing and all of that.
<pjb>
verisimilitude: note that the difficulty here, is when the file size metadata is not specified in bits, but in bytes (which can be different from octet by the way).
<pjb>
verisimilitude: clisp has to add a header to store the actuall bit size differential, since it cannot count on being able to save an additional metadata.
<verisimilitude>
Rephrase that for me, if you would, pjb.
<aeth>
pjb: In practice, a byte is an octet and a word is a nonnegative integer multiple of an octet. These are assumptions that essentially all future hardware will make (but some historical systems might not have made)
<pjb>
aeth: in practice, tapes have 9-bit per byte.
<verisimilitude>
The UNSIGNED-BYTE terminology clearly doesn't enfore octets.
<aeth>
verisimilitude: Yes, CL is more portable than you have to be. :-)
<pjb>
aeth: and also in practice permanent storage is not always done on hard disk using octets.
<aeth>
s/than you have to be/than you can be/
dale has joined #lisp
<verisimilitude>
Nevermind, I suppose. Anyway, what is that ninth bit usually used for, pjb? I'm not familiar with tape much.
<verisimilitude>
Is it just parity or other metadata?
<pjb>
verisimilitude: yes, probably parity. On the other hand, punched cards had 12-bit bytes.
<pjb>
verisimilitude: otherwise, you must learn about abstraction. This would restore your aesthetic sensibilities.
<verisimilitude>
All I described was a format that is a stream of bits, pjb.
<verisimilitude>
That is very portable.
<verisimilitude>
Am I simply misunderstanding what you wrote?
<pjb>
Yes, but you could have subfunctions, to decode the bytes into bits. and instead of collecting a list of them you could store them to a bit-vector.
<verisimilitude>
I feel we're miscommunicating, somehow.
<ym>
What's most convenient way to use (+ JavaScript WebKit-browser) as GUI with CL?
<no-defun-allowed>
The most convenient way is to not do that.
<ym>
There is no convenient native GUI in CL.
<no-defun-allowed>
Qtools and McCLIM make for better GUI tools.
<verisimilitude>
The most convenient way is to rewrite it in Common Lisp as much as is possible.
<no-defun-allowed>
I don't consider eating more memory than Emacs a good sign for a UI toolkit, nor does using JavaScript make it more palatable.
<ym>
I don't understand why use CLIM instead of CLX.
<djeis[m]>
CLIM is nicer and will eventually be portable.
<djeis[m]>
ie. not limited to X11
<djeis[m]>
Technically it already is.
<no-defun-allowed>
CLIM is higher level, focusing on presentations and widgets.
<djeis[m]>
It's just the SDL2-supporting backend is 3rd party and a bit of a mess.
<djeis[m]>
More or less works tho.
<aeth>
CLIM is high level. e.g. If I wrote a basic GUI system in OpenGL+SDL2, someone could write a CLIM backend for it.
<jackdaniel>
McCLIM works just fine. it is true that the only practical backend right now is clx.
<jackdaniel>
fact that it is under active development and has bugs doesn't mean it is wip, it is already usable as it is
<ym>
High level is when I write (circle 10 20 30) - some magic happens and I see a circle I asked for. I can't call new standard "more high level" just because it's brand new and more robust.
<verisimilitude>
Oh, of course this should be cleaned up and all of that, pjb.
<jackdaniel>
as of: why use McCLIM over CLX: clx is just an event queue and drawing primitives, CLIM gives you object identity on the screen, display, application abstraction and much more
<djeis[m]>
ym: Presentations and output recording are an abstraction atop even that.
<djeis[m]>
As are gadgets, for that matter.
<ym>
Cool.
<jackdaniel>
also it gives you a stream interface ;-)
<jackdaniel>
(draw circle of radious 50 at 100x100 at mcclim-stream)
<no-defun-allowed>
Nice
<aeth>
ym: CLIM is more high level in that someone could write a McCLIM backend or CLIM implementation on top of my GUI thing if I wrote a GUI thing. McCLIM-on-CLX, of course, being the only current example.
ntbre has joined #lisp
<ym>
But shouldn't I create a bunch of "context" before?
<jackdaniel>
I don't know what do you mean by context
<jackdaniel>
clx has graphics context, mcclim has panes and streams
<aeth>
CLIM could e.g. be ported to Mezzano's GUI system if they're not too incompatible
<jackdaniel>
which are "ordinary" class instances
<jackdaniel>
aeth: in fact there already is a working poc code
<jackdaniel>
newest mezzano demo has mcclim applications baked in
<no-defun-allowed>
Yeah, mezzano has some kind of CLIM.
<jackdaniel>
not that they are acceptably fast, but mezzano is not a demon of speed itself (yet)
<no-defun-allowed>
It also has quake.
<djeis[m]>
In a sense the "context" is baked into the stream, so part of it is that you have to create a stream somehow. That's not difficult tho.
<jackdaniel>
(defvar *my-stream* (open-window-stream)) is one way to do that ;-)
<djeis[m]>
Is painting on that threadsafe now?
<djeis[m]>
Or would you still want to do it in some kind of callback.
<jackdaniel>
no, I'm going to work on that *after* adding page support and alignment to clim-stream-panes
<jackdaniel>
you may schedule events or define commands which draw on a stream
<djeis[m]>
Fair enough.
<jackdaniel>
that is thread safe
<jackdaniel>
but if you asynchronously call (format *stream* "foo") ; ← that is not yet
<ym>
Where's this open-window-stream function?
<jackdaniel>
in clim package
<jackdaniel>
but we have a good plan to make all that thread-safe, it is just matter of time and motivation
* jackdaniel
hopes he did contribute to the discussion, now it is time to rest for him. \o
iovec has quit [Quit: Connection closed for inactivity]
<djeis[m]>
Bye then :)
Bob has quit [Read error: Connection reset by peer]
bobby has joined #lisp
<ym>
Wow. It works.
<ym>
Cool.
<ym>
Awesome.
borodust has quit [Quit: Leavin']
bobby has quit [Excess Flood]
<djeis[m]>
As we mentioned, you don't in practice want to just be writing to some random window stream from any thread tho. It'll generally work, and eventually that'll all be safe, but with the current version of McClim sometimes that will break things. If you learn a little more clim you'll find it's fairly easy to make sure your code is running as part of the window's own rendering process, and even in current McClim that's always
<djeis[m]>
safe.
bobby has joined #lisp
<djeis[m]>
Could also spin up the clim-listener (repl) and do your drawing in a with-room-for-graphics block, which renders it right in the window of the repl.
<djeis[m]>
And afaik all code run at the actual listener can safely draw to the listener, that's part of its design.
<jackdaniel>
↑ that's true (if you mean using *standard-output* in said listener)
fiveop has quit []
borodust has joined #lisp
<ym>
Ok, reading McCLIM documentation farther makes me understand why you all love it so much.
shka_ has quit [Ping timeout: 250 seconds]
kajo2 is now known as kajo
Oladon has quit [Quit: Leaving.]
tempate has quit [Quit: Leaving.]
<jackdaniel>
nothing to love, tool like any other. but it has certain adventages over clx
orivej has joined #lisp
<jackdaniel>
s/clx/raw clx/
<no-defun-allowed>
CLIM's pretty damn good compared to working with Tk or GTK though
random-nick has quit [Ping timeout: 245 seconds]
<ebrasca>
Can McCLIM work with opengl?
<djeis[m]>
Define "work with"?
<djeis[m]>
I mean, the short answer is no at the moment.
<djeis[m]>
An OpenGL backend could be written tho.
<aeth>
McCLIM had a legacy OpenGL backend a few years ago, but it was removed for being very legacy. Probably circa 2000 style OpenGL
flazh has quit [Ping timeout: 240 seconds]
<aeth>
OpenGL isn't sufficient. You would also need something else. e.g. cl-opengl + cl-sdl2
<aeth>
Even then, it would probably be easier to work in layers, and have McCLIM target a layer on top of cl-opengl + cl-sdl2 that makes things look a bit more like what it would expect in a backend.
flazh has joined #lisp
<aeth>
You would also need to think about what a window is. Do you want to literally create new SDL windows or do you want to create fake windows within the one fullscreen 3D application?
<aeth>
The latter would be much more useful for something like a game.
<djeis[m]>
Could definitely do that tho.
<djeis[m]>
It'd involve a decent bit of infrastructure, but I'd bet you could implement a frame manager that worked that way.
<aeth>
I expect that someone will write a minimal OpenGL-based GUI system and someone else will port McCLIM to it or write a CLIM implementation on top of it.
<djeis[m]>
That'd be neat.
<ebrasca>
mmm , what about McCLIM on top of cepl?
<djeis[m]>
It could be done, but it'd involve a lot of work if you actually wanted to take advantage of hardware acceleration.
<djeis[m]>
If all you care about is platform independence there's the CLDK backend, but I'm testing it atm and it seems to have bitrotten a smidge.
<ebrasca>
What is this "bitrotten" problem?
<djeis[m]>
Trouble with 3rd party libraries, they don't keep up. Was working just fine a few months ago, but McClim is a moving target for a backend I'd guess.
<djeis[m]>
It's referencing a package that doesn't exist.
<djeis[m]>
I'm sure the symbol's it's looking for still exist somewhere, they're just not in the package where it's looking for them.
<djeis[m]>
*symbols
<aeth>
ebrasca: I'm guessing that CEPL doesn't have enough of what a McCLIM backend expects. For anything designed for a 3D application, you would essentially have to write a fake window system for it, where you can create 'windows' within the graphical application, move them around, etc.
<djeis[m]>
Yea, there'd be a lot of infrastructure between CEPL and McClim to actually make is useful as a backend.
<aeth>
You'd also need text rendering.
<djeis[m]>
McClim has a pure-lisp text renderer.
<djeis[m]>
It also supports freetype, if memory serves, but it defaults to the internal one.
frodef has quit [Ping timeout: 246 seconds]
<aeth>
djeis[m]: I would personally leave text rendering to the lower level, especially if it's text rendering in a 3D application.
<pjb>
Unless you want it to be good, in which case you write your own metafont.
<ebrasca>
Whe can make cepl inside McCLIM or McCLIM inside cepl or some combination?
<djeis[m]>
I mean, sure, definitely could do that. I think it'd require you to implement a lot more of the CLIM drawing primitives in terms of GL instead of relying on CLIM's own software renderer tho.
<djeis[m]>
*McClim's own
rumbler3_ has quit [Remote host closed the connection]
<aeth>
ebrasca: 3D applications work differently than most. You want OpenGL and a gaming-oriented input/window portability library like SDL2 (there are probably close to a dozen options, but SDL2 is the most popular). You also want to do everything within one large, probably fullscreen, window, reinventing window management (you probably don't want your game or CAD or 3D modeller to actually have new, separate windows, just fake 'windows' within t
<aeth>
So to CLIM-on-GL a 'window' would really just be a rectangle that can move around within the real OS window.
<aeth>
The efficient and desirable way to render text is probably going to be different than the mainstream way, too.
orivej has quit [Remote host closed the connection]
<aeth>
So something like CEPL would be several layers underneath CLIM since you would target the fake window system on top of a framework on top of cl-opengl+cl-sdl2
<ebrasca>
pjb: Can whe have someting like this in lisp?
<no-defun-allowed>
of course, but have you got the hardware?
<ebrasca>
What hardware?
gxt has joined #lisp
karlosz has joined #lisp
<aeth>
ebrasca: VR is hard to do in a language like Common Lisp because it requires a much higher framerate. Probably above 100 frames per second (which means every action needs to be done in less than 0.01 seconds, including garbage collection pauses!)
<aeth>
It also requires a very high resolution. Today's VR headsets don't really have a good enough resolution. 4k is probably good enough for a TV viewing distance. A monitor, closer to your face, probably could use 8k. VR probably could use 16k or above. The closer it is to your face, the more pixels you need to avoid seeing pixels.
<no-defun-allowed>
VR also requires significant investment in hardware off the bat in cee, too.
voidlily has quit [Ping timeout: 240 seconds]
* ebrasca
don't undestand. He likes to think he is very good programer.
orivej has quit [Remote host closed the connection]
<aeth>
ebrasca: Virtual Reality is real time programming. Instead of thinking in terms of batches, you think in terms of actions done in a time interval. Instead of running foo in 1.4 seconds, you run tiny little pieces pieces of foo in 0.0005 seconds and need to leave room for every other tiny little piece that needs to be done that tick of time.
* ebrasca
don't know what to make cl-vulkan triangle , btrfs/etx4/cache for mezzano ...
<aeth>
Unlike regular game programming you have three issues: (1) the ideal resolution is higher, (2) the ideal framerate is higher (the time to do things is 1/fps, so that means the time to do things, at least related to rendering, is smaller), and (3) missing a frame (by taking too long somewhere) is more problematic because you might make your user ill
<pjb>
aeth: it's dumb to say that CL makes VR hard once CL has been used for crash bandicot.
Arcaelyx has joined #lisp
<pjb>
aeth: you didn't understand anything about lisp. or this /topic
orivej has joined #lisp
<no-defun-allowed>
:/
<no-defun-allowed>
Crash Bandicoot didn't run in a CL system.
<no-defun-allowed>
An embedded (mock)Lisp was used which was compiled and debugged from a CL
<aeth>
pjb: Assuming you're correct (and you're not quite correct here) that game was in 30 FPS. (/ 30d0) => 0.03333...d0 so You had that much time to do your computations. (It probably did everything in the same framerate without logic independent of rendering.) For VR you're probably thinking in terms of at least (/ 90d0) => 0.01111...d0
<pjb>
aeth: go read about it!
<pjb>
no-defun-allowed: exactly.
<no-defun-allowed>
So, it is a problem because their Lisp-like is not CL.
<aeth>
Of course, modern games (should) do logic independently of the rendering framerate so your logic could e.g. be a constant 0.01 s even when you have 90 FPS or 144 FPS at the display, but there are some things that would have to run with the graphical tick even if your logic tick is every 10 FPS or so.
<no-defun-allowed>
That's a lot of inline assembler.
<aeth>
pjb: It's funny how you think that I'm ignorant of the topic, though. I'm writing the only Common Lisp game engine that focuses on high performance, high frame rate, and real time over convenience. So when I'm complete it will be the most likely to be usable on actual VR systems without first porting a RTGC to a CL implementation.
<aeth>
My provided part of the game loop is nonconsing which means the GC will only run when the user wants it to if that's a concern of the user. (Or the user can cons, which could trigger the GC at unexpected times, and it's up to the user, not the framework or engine, where to be on convenience vs. dependable performance.)
<aeth>
And you definitely couldn't do this on a PlayStation.
meepdeew has joined #lisp
voidlily has joined #lisp
ntbre has quit [Quit: ntbre]
Lord_of_Life has quit [Ping timeout: 245 seconds]
Lord_of_Life has joined #lisp
kajo has quit [Quit: From my rotting body, flowers shall grow and I am in them and that is eternity. -- E. M.]
<ebrasca>
aeth: cool you have your own project.
<aeth>
Although it's not really about being usable on $foo it's about how much you can safely do on $foo to stay within the time limitations