<clacke[m]>
I looked around quickly for any asciidoc-based wiki. There isn't any, just some people on the asciidoc saying they would like one. But ikiwiki has an asciidoc plugin.
dtornabene has joined #picolisp
aw- has joined #picolisp
dtornabene has quit [Quit: Leaving]
orivej has quit [Ping timeout: 255 seconds]
aw- has quit [Quit: Leaving.]
aw- has joined #picolisp
orivej has joined #picolisp
cilz has joined #picolisp
<cilz>
good morning guys
<Regenaxer>
Hi cilz!
<cilz>
hello Regenaxer
<beneroth>
Good morning cilz, Regenaxer :)
<Regenaxer>
He beneroth!
<cilz>
hello Beneroth
<Regenaxer>
I thought a little more about the ideas around 'till'
<Regenaxer>
(till "chars" 'flg "str1" "str2" ..)
<Regenaxer>
I think it is not worth the effort
<Regenaxer>
The thing is that 'till' is different from 'from' or 'echo' in this regard
<Regenaxer>
'till' does not return *which* pattern was matched, so it is less useful
<Regenaxer>
I think it must be handled programatically
<beneroth>
T. Though (till NIL 'flg "str") would still be useful
<Regenaxer>
I usually do several 'from's till I read the point
<Regenaxer>
yes, a little, but in my experience not very much
<beneroth>
I increasingly use (from) and (till) instead of (split (line) ...)
<Regenaxer>
yes
<beneroth>
yeah its about programmer UX
<Regenaxer>
splitting a line is not useful in a string
<Regenaxer>
to go till a pattern, you can program a loop and do any general search
<Regenaxer>
Example:
<beneroth>
T
<beneroth>
(state) ftw
<Regenaxer>
(make
<Regenaxer>
(loop
<Regenaxer>
(NIL (chain (till "x")))
<Regenaxer>
(char) # Skip "x"
<Regenaxer>
(T (= "y" (peek)))
<Regenaxer>
(link "x" (char)) ) )
<Regenaxer>
This looks for "xy", skipping single "x"es
<beneroth>
simpler than using a full-blown FSM with (state) :)
<Regenaxer>
yes
<Regenaxer>
The loop can be arbitrarily involved
<Regenaxer>
'till' a pattern has the problem that we don't know *which* pattern was reached
<Regenaxer>
because it returns the things in between
<Regenaxer>
for 'echo' it makes much more sense
<Regenaxer>
of for 'from'
<Regenaxer>
So, it *would* be a little useful, but not very much I believe
<beneroth>
one aspect is: it is very simple to read stuff with picolisp when you can trust the input. much more simple than in most stacks (and very lightweight). but when you can't trust the input, you have to clobber up the code with many failure checks
<Regenaxer>
yes
<beneroth>
of course, this is inherent to the task, but it's not so easy to organise it in the code in a nice way
<Regenaxer>
One has to be creative ;)
<beneroth>
T
<beneroth>
and reduce whatever can be reduced. simpler is better.
<Regenaxer>
exactly
<aw->
hi beneroth, Regenaxer
<Regenaxer>
Hi aw-!
orivej has quit [Ping timeout: 264 seconds]
<Regenaxer>
So, in summary, I think the best way is to operate on the stream in an intelligent way, using 'from' to jump near the points of interest, and then primitives like 'char', 'peek', 'skip' and also 'till', 'line' etc.
<Regenaxer>
Sometimes also 'read' makes sense
<beneroth>
read: if you can trust the input and it doesn't use (unofficial, language-specific) de-facto standards like /uXXXX notations
<beneroth>
:)
<beneroth>
(just for the log)
<Regenaxer>
T
<Regenaxer>
Most of all, there may be read macros
<beneroth>
picolisps problem with the state of mainstream IT stacks is, that picolisp is to sane and rational. the creator probably underestimated the stupid weird ways of other tech creators. ;-)
<Regenaxer>
hehe, not even underestimated, but completely ignorant of ;)
<beneroth>
haha, so T. I wanted to word it nicer :P
<Regenaxer>
:)
<beneroth>
ignorance is bliss.
<Regenaxer>
T
<beneroth>
btw \uXXXX is also a problem for many other languages (e.g. C and C++. you need libraries, or code it yourself)
<beneroth>
C++ boost strings library can't handle it
<Regenaxer>
C rather sticks with octal notation for stupid historical reasons
<Regenaxer>
So ohers inherited it too
<Regenaxer>
even vim does, when icrementing with ^A iirc
<beneroth>
the designer of C# once said that it (well the byte-format it is compiled to, which then gets interpreted) is incorporating the flaws of C and Java. it shows.
<aw->
beneroth: what's wrong with \uXXXX ?
<beneroth>
it's inferior to just using UTF-8 encoding, especially when it is put into text files which are UTF-8 encoded.
<beneroth>
and afaik its no rfc, its a encoding some languages (java, python, php, ..) came up with, but it's really so widely supported.
<beneroth>
s/really/not really
<aw->
oh i see
<aw->
yeah i found it weird that JSON spec requires parsing of those strings
<aw->
but then, it's really helpful in cases where certain langauges **dont** support UTF-8 or proper encoding
<aw->
like java
<aw->
or even more recent: S3
<beneroth>
S?
<beneroth>
S3?
<Regenaxer>
I always forget about it, but pil has its own funny syntax for arbitrar chars:
<Regenaxer>
: "abc\9786\def"
<Regenaxer>
-> "abc☺def"
<Regenaxer>
At least less verbose than \uXXXX
<aw->
amazon S3 has difficulty with character encodings
<cess11_>
I think I like 'till as it is.
<cess11_>
And encoding is a nightmare.
karswell_ has joined #picolisp
<cess11_>
I almost always outsource it, either iconv or w3m usually. But pil can take a beating, the terminal interface usually breaks before the pil VM does when the input is nasty.
<cess11_>
At least when pulling in random data from the Internet.
stultulo has joined #picolisp
<cess11_>
viaken: T, though I think I'd have trouble going from pil DB back to just about anything else now.
<aw->
Regenaxer: oh yes I remembered that recently, interesting syntax, but pretty useful
<aw->
bbl
<Regenaxer>
cu :)
viaken2 has joined #picolisp
aw- has quit [Quit: Leaving.]
karswell has quit [*.net *.split]
viaken has quit [*.net *.split]
f8l has quit [*.net *.split]
stultulo is now known as f8l
mtsd has joined #picolisp
orivej has joined #picolisp
aw- has joined #picolisp
<aw->
beneroth: I had a look at Rust ;)
<aw->
it quickly made me want to return to PicoLisp
<aw->
too much hype with these new languages
<beneroth>
what made you run?
<beneroth>
some specific examples?
<aw->
most obvious is the language syntax is not exactly simple/pretty
<aw->
it has some really strange features which I don't agree with
<aw->
example: let varname = value1 # assigns value1 to the immutable variable 'varname'
<aw->
_immutable_
<aw->
but right below that, you can do something like: let varname :u32 = 25
<tankf33der>
yea
<aw->
so depending on your coding style, you can easily overwrite an IMMUTABLE variable
<tankf33der>
but memory safety for free is the power too
<aw->
makes no sense
<aw->
overwrite AND change the type
<aw->
what's the point of having immutable variables then?
<aw->
it's a bad language design decision
<Regenaxer>
I would call that "constant" instead of "variable"
<aw->
tankf33der: yes memory safety, but it also provides the ability to malloc and free (and requires it) for things which are considered "unsafe" such as calling C FFI… ugh
<aw->
Regenaxer: oh no, they have constants too!
<Regenaxer>
I see, so these are local constants?
<aw->
those which are _really_ constants, and they can't be the result of an expression
<Regenaxer>
ok, so the compiler can optimize them
<aw->
yes that's the point
<tankf33der>
yes, picolisp much better
<aw->
beneroth: i also dislike the separation of "statements" and "expressions"
<tankf33der>
i feel alive when coding on picolisp
<aw->
so previous example: let variable = value # is a statement, it can't return a value
<aw->
dislike
<aw->
tankf33der: same here
<aw->
these are basic things, makes the language more verbose, more coding and boilerplate for things which are so much simpler in Lisp
<beneroth>
<tankf33der> i feel alive when coding on picolisp
<beneroth>
T
<beneroth>
aw-, ok, sounds like they wanted to solve the issues by adding rules. I don't believe they can beat C++ in that game xD
<beneroth>
what is about platform (OS) dependencies? is the situation better in Rust than with C/C++ ?
<aw->
i didn't get that far
<beneroth>
You can write nice and perfectly automatically memory-managed code in C++
<aw->
but it seems the Rust compiler is tightly coupled to the version of your code
<beneroth>
wow
<aw->
so what you write today might not compile tomorrow
<beneroth>
ok, so probably worse than C++ then
<beneroth>
the "compile today, compile tomorrow" is one of C++'s holy laws... doesn't work always, but surprisingly well. a reason for a lot of cruft in the language.
<aw->
well C as well
<aw->
can you imagine breaking features in C ?
<beneroth>
T. though its simpler with C, as C is simpler - which as disadvantage just pushes a lot stuff into platform-dependent libraries
<aw->
i said to my friend earlier: "we decided to rename char[] to string[]" .. wouldn't go well for C developers
<Regenaxer>
:)
<beneroth>
I know some in C++ (e.g. scoping of iteration variables within for-loops), but I haven't witnessed any in C. I'm too young for the kindergarten problems of C.
<beneroth>
a char is a byte :)
<beneroth>
aw-, have you ever tried out Haskell? the syntax is pushing me away from it, especially after getting used to Sexpr
<aw->
yes I have, a few months before discovering PicoLisp
<beneroth>
what did you make go away from it?
<aw->
months of hell
<aw->
well after a month of banging on my keyboard, I finally got Hello World working ;)
<beneroth>
ouch
<aw->
haha i exaggerate
<aw->
i found it extremely difficult to be productive in Haskell
<beneroth>
I have a friend who loves it. but he has no practical experience outside academia
<aw->
the language also constantly introduces breaking changes
<aw->
so half the code you find online in tutorials and github don't even work
<beneroth>
I tend to think that its take on strong typing is the only meaningful strong typing (vs. duck typing à la picolisp), and good idea for code which really should be both secure and safe
<beneroth>
ah
<beneroth>
ok
<aw->
and the code that does work is often ridiculously un-documented, and it's Haskell, therefore quite hard to understand even how to use it
<beneroth>
that's a big downturn
<beneroth>
ok
<beneroth>
that surprises me, I would expect it to be more matured and stable, afaik it started early 90s
<aw->
but you know, Haskell was a nice experience to read and get a glimpse of what Unicorns would be like if they existed
<aw->
but in reality it was crappy. Lisp is so much more fun
<beneroth>
I think of picolisp (and Regenaxers career) as an unicorn
<beneroth>
(in the good sense of the word9
<aw->
i agree
<beneroth>
the other thing I should look at eventually is Erlang, I guess
<aw->
it's nice being able to "trust" the language I use daily
<beneroth>
but the syntax makes me shudder, too
<beneroth>
T
<beneroth>
that is a very big property
<aw->
and Regenaxer doesn't deprecate language features every week
<beneroth>
and I just love the small size and small size of environment of it. not hundreds of MB of generated XML, YAML, generated code, whatnot. not multiple clicks on "build" having different effects. not having to "build" multiple times until it somehow invalidates the right cached files to produce something runable.
<aw->
imagine if Regenaxer decided to remove '(prin)' because he doesn't use it..
<aw->
beneroth: agreed! i like that i can compile 64-bit pil in 500ms
<mtsd>
beneroth, I second that. The small, focused, environment is fantastic. To the point
<aw->
interpreter loads so fast, just run it do stuff, go back to doing whatever
<beneroth>
I think that is the biggest risk for picolisp in the longterm, that it might be branch out into multiple picolisp dialects. though we're a small quite closely-knit community, so I guess we should be able to create a kind of directorate or new benevolent chief
<mtsd>
I have loads of room left on the latest VPS I set up, since the provider did not sell smaller disks than 5 GB :)
<aw->
mtsd: it's nice when "make" just makes.. done in a few second, use right away
<aw->
beneroth: who wants to fork picolisp?
<Regenaxer>
Yeah, like C
<Regenaxer>
nobody really forks C
<mtsd>
Speaking for myself, I am very happy with picolisp the way it is. Not to mention not compentent enough to fork it ;)
<Regenaxer>
C++ is something different
<beneroth>
nobody. but some far day away it could happen.
<beneroth>
C++ is a merge of all possible forks of C++ xD
<Regenaxer>
true
<cess11_>
Elixir might be more interesting and nicer to look at than Erlang proper.
<beneroth>
nobody programs in C++, everyone just programs in a subset of it.
<beneroth>
(in different subsets of course)
<cess11_>
Not sure about Elm but I think it also runs on the same VM.
<beneroth>
ok, thanks for the input cess11_ :)
<cess11_>
At least I liked Elixir except for the parensless syntax when I dabbled a little in it.
<cess11_>
Unless I'm mixing it up with something else, not entirely sure. It is however a good language and platform for web services.
<cess11_>
I thought OCaml was nicer than Haskell as well, more hackish and practical.
<beneroth>
I'm interest (in the longterm) in high concurrency
<beneroth>
I would guess there are some things which are easier to achieve with erlang/elixier than picolisp in that field (could still call picolisp though).
<aw->
beneroth: it's probably worth taking a few hours trying out these other languages as well, rather than relying on other people's (including my own) biased opinions ;)
<cess11_>
I think pil will be the way to go, exceptional IPC and 'co capabilities and fairly direct manipulation of memory and CPU.
<beneroth>
aw-, T. though I value your opinions much and I have some trust into your judging abilities, as your are fellow picolispers ;)
<cess11_>
But it might be rough to emulate the redundancy of the Erlang VM.
<beneroth>
aye
<aw->
thanks!
<beneroth>
cess11_, well maybe building a system for that on top of the excellent pil capabilities, and then implement them as pil asm libraries (like ht:) to gain the speed. might be enough.
<cess11_>
Take a look at Factor if you haven't, it's like a Forth but with whistles and bells and lots of libs and snippets already available.
<beneroth>
Regenaxer, any rule of thumb numbers how much faster an pil asm implementation is vs. pil lisp code? :P
<aw->
btw I was thinking, it would be really cool if PicoLisp had a build system to compile various versions of Pil automatically, for different architectures
<cess11_>
Agreed, I would prefer something like that to splitting services over VM:s or languages.
<Regenaxer>
I would say factor 10 to 20
<beneroth>
cess11_, I think I don't have Factor on my radar. I check it out, thanks for the hint!
<cess11_>
factorcode.org
viaken2 is now known as viaken
<cess11_>
If you install under an Arch or headless Debian, add NO_UI=1 to build.sh to keep it from complaining about some GTK lib when you run it.
<cess11_>
aw-: I agree, and I think something like that might be necessary in the future, due to more architectures coming to market.
<beneroth>
noted, thanks
<beneroth>
Regenaxer, thx
<Regenaxer>
or, more correct, 1 .. 20
<Regenaxer>
depends of course
<beneroth>
20 is the rule of thumb number for enum vs pil64, too, right
<aw->
cess11_: i have one lib which I test on Travis with 4 diff versions of PicoLisp, but it's insufficient since Pil has many more targets
<beneroth>
T
<aw->
arm64 etc
<aw->
bbl
<aw->
bbl tomorrow. going to bed early
<beneroth>
good night aw-
aw- has quit [Quit: Leaving.]
<mtsd>
I hope I can find the time to dig a little deeper into picolisp
<mtsd>
pil asm etc
<mtsd>
I have had some success building things at work in picolisp lately. Things are moving in the right direction, I think
<Regenaxer>
perfect :)
<beneroth>
nice :)
<mtsd>
Trying to pick things people will depend on and implement in pil. Highly subversive strategy ;)
<beneroth>
I'm probably able to sell another custom webapp implemented in pil, selling point being speed of development. intermediate solution, should get replaced by other stuff in 2-3 years, but we will see if this happens then ;)
<beneroth>
(and I actually want to stop doing pil projects a bit because my framework needs some more polishing)
<beneroth>
and another (payed) form.l project is still on the todo list
<mtsd>
I simply don't mention lisp until it is too late, when people have already been using the app for some time :)
<mtsd>
worked great so far, haha
<beneroth>
well if it works, then people don't care about the technology.
<Regenaxer>
T
<beneroth>
they only fear to be blamed with the technology choice when it fails
<beneroth>
if you don't tell them you also make them a service, because then they have plausible deniability, then they can blame you and be safe. a bit risk for you maybe, though.
<beneroth>
I have one pil-based project which got a lot of changes after golive. so far it worked well, less hazzle than expected.
<beneroth>
psh (pil repl/shell into running application server/software) is a great tool
<beneroth>
live-upates are no problem.
<beneroth>
no downtimes, at most maybe half a second when doing a restart to properly re-load core files.
<beneroth>
industry state of the art stacks have problems beating that.
<tankf33der>
i wanna create this tool on picolisp:
<beneroth>
oh, do that tankf33der! I will integrate it into my ongoing package management attempt
<beneroth>
I see signing as a absolute requirement for package. can't understand why its not common (it isn't at all, even debian packages are kinda only checksummed), when it's not unlikely that some actors are able to MitM-attack even TLS (many package distributions still use plain http)
<beneroth>
one should be able to be able to track/blame the person/organisation who distributed a certain piece of software with defects.
cilz has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 260 seconds]
<cess11_>
One reason for signing not being applied is that it requires chains or webs of trust and that is contrary to capitalist competition, so either one needs to do it for free and lots of others must participate for free too, or one needs a monopoly and gets extremely vulnerable in other ways.
<cess11_>
Really tricky problem, it's sad that many commercial banks and other companies think that simple databases are the solution, like 'blockchain'.
<cess11_>
In an OK world this would have been solved when the first NPM-scandals landed, at the latest. In a perfect one we'd have this as best practice since at least the eighties, around when I was born.
mtsd has quit [Quit: Leaving]
<beneroth>
well because free/open web of trust is too expensive/people not educated enough for it, we currently have monopolies (NPM is a monopoly)
<beneroth>
my imagination: devs sign their packages, and a "repo/distributor" additionally signs the packages it distributes. this way you can choose to trust individual devs, or specific repos. there could be repos which do extensive checks (e.g. your org/company internal IT department checking updates before distributing them, as it is partly done today), and others which only do partial or even no checks (e.g. free hoster on the internet, collecting and distributi
<beneroth>
ng everything they get their hands on)
<beneroth>
either way, if shit happens (it always does, eventually), you can check the signatures to see through which repos/distributors from which dev(s) the piece comes. then you can decide if you don't trust one or all parties on this chain anymore, or if you want have additional warnings/checks when getting stuff this way, or whatever
<beneroth>
current state of the art is "well this can happen. we don't know how or who. shrugs.".
<beneroth>
problem is, this current state is favoured by most participants because it is the one with the lowest efforts required.
<beneroth>
"oh most hospitals of our nation are unable to work anymore because of IT failure (UK). well, such things happen. bad world. too bad we can't do anything. such stuff happens, nobody is blame (well the russian/or-other-current-political-scapegoat were it, we knew it!)"
<cess11_>
Yeah.
<beneroth>
any input for my vision/imagination? practical way? worthwhile attempt or waste anyway?
* beneroth
is still undecided between "let's go into politics and improve things" vs. Bucky Fuller view: "politics is quixotic. lets just focus on innovation and progress, and change the reality ignoring/in spite of politics"
* beneroth
worries the best approach is a mix of both, but then which mix. hard to compute.
<beneroth>
bbl
<cess11_>
There are lots of bubbles in IT and global finance so even if something like that is put into practice soon it is highly likely that a later recession will force it aside through it being more competitive and easier to survive to not perform these security measures.
<cess11_>
For smaller subcultural and FOSS oriented communities it will work fine, I think.
<cess11_>
But then the trust issue is mostly solved anyway, since one is known and trusted in the community to about the extent one is participating and/or contributing.
<cess11_>
As in it will be hard to argue for adoption of such techniques, unless it is obvious that the community as well as single members would benefit quite a bit from adoption.
<cess11_>
Another model is to only write codebases small enough for a few persons to audit it thoroughly without too much hassle.
<cess11_>
Which sort of is the picolisp way as I understand it.
cilz has joined #picolisp
<Regenaxer>
cess11_, this is true
orivej has joined #picolisp
cilz has quit [Ping timeout: 260 seconds]
alexshendi has joined #picolisp
alexshendi has quit [Ping timeout: 246 seconds]
alexshendi has joined #picolisp
alexshendi has quit [Read error: Connection reset by peer]
alexshendi has joined #picolisp
orivej has quit [Ping timeout: 255 seconds]
alexshendi has quit [Read error: Connection reset by peer]