freenode/#lisp - IRC Chatlog
Search
3:38:27
verisimilitude
I was referring to scraping websites that may have tricks involving JavaScript or cookies, but nothing to that extent, no.
3:39:43
sindan
the first couple of times i got cross-eyed looking at obfuscated js i abandoned my 90s era trick of trying to dig the html in any way.
3:40:40
verisimilitude
I've only come across a few websites comprised almost entirely of JavaScript and not one was worth scraping.
3:41:13
verisimilitude
I simply noticed the conversation and noted how I've been interested in writing Common Lisp clients of sorts for a few websites or types of websites.
3:41:30
verisimilitude
I'm glad I didn't bother researching into how tumblr works, considering that would've been a waste.
3:43:08
sindan
I've come across a few, specially if they try to make it hard to copy. Libraries, for one. I wrote a python client to download books.
3:44:08
sindan
from two libraries, one spanish, one norwegian. Piece of cake with selenium and the python wrapper for it.
5:33:32
krwq
Hey, does anyone know if there are any circumstances where this code: https://pastebin.com/gnqUAwdZ can fail (assuming 123 is not constant)
5:36:32
krwq
i converted it to not use *standard-output* and it never failed again but I'm curious if I'm missing something or is it like a sbcl bug
5:37:50
krwq
im almost sure the extra character was the '.' coming from quicklisp which was loading my system
5:40:23
krwq
the code was working for a while and then i started updating various systems and it suddenly started failing
5:41:03
krwq
and then when i used one of the restarts with 'recompile' in the name it loaded everything fine
5:41:40
krwq
it was super weird but it would be nice to track this down is it might bite me or someone else in the future (assuming im not missing something)
5:48:51
no-defun-allowed
you'd also have to change the FORMAT target to that stream instead of T as well
5:50:30
krwq
so I'm not sure I'll be able to repro right now, when i don't touch *standard-output* everything works fine
5:51:25
krwq
thrig: but when i do with-output-to-string it technically is not using the same *standard-output*
5:53:39
krwq
without clearing .cache/common-lisp no repro, after clearing (that's when it happened the first time) i got repro
6:00:08
krwq
hopefully beach comes back from his break soon and explains that to or at least say that's a bug in sbcl or something - it bothers me since weekend and can't find the answer :P
6:01:38
edgar-rft
krwq: *standard-output* might be buffered. Try FORCE-OUTPUT and/or FINISH-OUTPUT before and after printing to *standard-output*
6:07:49
krwq
and also even if that is in fact buffering issue it technically should buffer different stream, shouldn't it?
6:10:29
krwq
the extra '.' seems to be before my output so i presume putting it after won't make a difference
6:33:37
buffergn0me
FINISH-OUTPUT is supposed to wait until buffered output is flushed before returning. FORCE-OUTPUT can issue an async flush and return right away
13:39:33
margaritamike
Any python people here know if Python's macropy is about as good as Common Lisp's macro system? https://github.com/lihaoyi/macropy
13:41:02
beach
margaritamike: If the answer is yes, what would you do with it? Leave #lisp and go program in Python instead?
13:41:47
margaritamike
Well just wondering about python's ability to make programs that write programs in python
13:45:17
dlowe
This is a good topic for ##lisp which is more about the lisp family and lispy languages
13:47:04
margaritamike
Because I want to use Common Lisp to experiement with some things from some cool papers that use lisp from back in the day, but only if the meta abstraction properties lisp provides can't be found elsewhere
13:48:01
schweers
margaritamike: why would you only want to use lisp if you can’t find these things in lesser^Wother languages?
13:50:20
White_Flame
any language can do anything, with unlimited hoops to jump through as a tradeoff
13:51:18
White_Flame
lisp macros are basically the easiest-to-accomplish full macro system in popular use
13:51:55
White_Flame
the python docs for that look quite involved, with restrictions on when it can run (not in the main class), dealing with AST nodes, and a ton of tools to try to help
13:58:22
margaritamike
White_Flame: so if python can do that, what the heck is left for it to be on par with lisp
13:59:23
White_Flame
("any language can do that" obviously assuming infinite tolerance for verbosity, multiple build layers, etc)
14:00:07
beach
margaritamike: Those don't have precise definitions, which is why it is futile to try to compare languages.
14:00:31
beach
margaritamike: And that is probably also why people can get away with suboptimal choices of languages for important projects.
14:01:34
White_Flame
then you really don't have any context to know what options are "better" than another, so simply learn stuff
14:02:01
White_Flame
once you know how to do something, then you can compare it to other languages and see if it looks better and addresses pain points you had along the way
14:02:25
White_Flame
but without knowing either, "which is better?" "is it good enough?" etc has no context to answer into
14:03:43
White_Flame
"better integrated" however probably is more precise, as lisp uses its natural data structures and list operations to deal with macro transforms, while python needs ast node classes and its whole set of methods on those
14:04:32
White_Flame
plus, I'm not sure that Python has well-defined boundaries of compile-/load-/run-time and what is defined when, for situations like this where python code runs during compilation time
14:32:45
schweers
Why this question whether or not it is on par with lisp? I understand if you want to know it in order to have better mental context. But otherwise ... just use lisp?
14:35:21
jackdaniel
I agree with schweers. Putting aside communities, ecosystem, performance, verbosity and personal taste lisp is as good/bad as python or practically any other programming language because there is not much more space for comparison
14:41:53
schweers
Sorry if I sounded mean. I get that one wants to compare how different approaches are, and maybe find out whether these weird lisp people really have valid claims.
14:42:24
schweers
I just wonder why some languages supposedly evolve closer and closer to lisp. If lisp is what you want, just use it.
15:04:21
dansa
I've been `processing' the literature (since the 80s and 90s to present time) on DSL and trying to understand the state-of-the-art of building and applying DLS to problems-in-general and I'm surprised to see how little Lisp languages are mentioned. I haven't found yet a single mention of PLT Scheme and more interestingly no mention of Racket at all. (I have read various papers from the first
15:04:21
dansa
decade of the current century.) In contrast, Haskell is mentioned all the time and I find that very surprising. Are even researchers ignoring Lisp?
15:07:42
dansa
I think any DSL research today should always be compared to the way Lisp deals with the problem because Lisp seems to be *the* language for DSL --- along with Haskell, I could concede. Racket seems the forefront of DSL today. I'm not aware of any well-known DSL-building problem that's not properly solved by Racket.
15:08:27
schweers
I’m not in academia, but I do get the impression that static typing is still all the rage in some circles. So lisp may be ignored on those grounds alone.
15:08:33
dlowe
If the discussion is going to involve cross-lisp comparison, we should take it to ##lisp
15:12:18
White_Flame
however, I think DSLs have more to do with language design and representing problem-space abstractions well