<yxhuvud>
well, they have totally different patterns for multithreading. some parts are better, some worse but mostly just different from what I've seen
<FromGitter>
<codenoid> current process will exit ?, o.o, umm, i want call other binary program, currently i use ``, or crystal have method for that ?
<RX14>
@codenoid uhh Process.run
<RX14>
did you read the docs?
<FromGitter>
<codenoid> it's call other app ?, i missunderstanding
<Papierkorb>
codenoid, `exec` doesn't spawn a new process. it replaces your process with the new one. Your process stops existing, it doesn't exit either.
<RX14>
@codenoid `` uses Process.run
<RX14>
so does system()
<Papierkorb>
codenoid, you know how #exit doesn't actually return, but quits the process right? .exec also doesn't return (Except if there was an issue), but instead of quitting the process, it loads a entirely different program and starts it, replacing your process.
<FromGitter>
<codenoid> well cool, i can get pid from that without `$!`
<Papierkorb>
codenoid, exec() is part of POSIX, so on all POSIX compliant systems, it exists and does the same thing
<RX14>
Process.run is basically just Process.new followed by process.wait
<FromGitter>
<codenoid> but process#run doesnt have unbuffered method, can i put Process#run inside `fork` ? , i'll try
<RX14>
what
<RX14>
i mean yes you can
<RX14>
but you probably don't understand
<RX14>
@codenoid what are you trying to do?
<RX14>
in the larger sense
<Papierkorb>
TIL execveat. That should be usable to exec() into an unlinked fd lul.
<FromGitter>
<codenoid> i have a http api for creating new process or kill the process with proccess pid
<FromGitter>
<codenoid> *run a new application
<RX14>
if all you're doing is creating new processes, the only methods you want to call are Process.new or Process.run
<RX14>
ignore Process.exec and Process.fork
<RX14>
you don't need them
<RX14>
Papierkorb, too many functions in the exec family
<Papierkorb>
yes lol
<Papierkorb>
oh fexecve allows to do the same (for the given abuse-case)
<FromGitter>
<codenoid> yes ,haha, i use fork just for flushing http response :shipit:
<Papierkorb>
... huh
<RX14>
what
<Papierkorb>
codenoid, that sounds rather dangerous. You shouldn't need that in the first place.
<RX14>
i think thats enough #crystal-lang for today
<FromGitter>
<codenoid> yes, fork in HTTP::Client
<FromGitter>
<codenoid> okay then
<RX14>
i mean yes, Process.fork does have the side-effect of flushing all file descriptors
<RX14>
but if I saw that I would have put it down to a deliberate attempt to write terrible code
<Papierkorb>
Please don't blindly #fork. fork() is one of the most mis-understood (and hard to understand) mechanisms of POSIX
<RX14>
Papierkorb, honestly I don't see much of a usecase for fork in 99.99% of applications now we have SO_REUSEPORT
<RX14>
before that is was just 99.9%
<FromGitter>
<codenoid> '-' well i puts a fork inside a fork for more fork in my app
<FromGitter>
<codenoid> HTTP::Client.post => Process.run("./app") # buffer, so i do fork process in HTTP::Client
<FromGitter>
<sam0x17> @codenoid there is definitely a better way to do what you are trying to do
<FromGitter>
<codenoid> but I have not done that yet, because that's just a plan
<FromGitter>
<codenoid> currently i call external app directly via "`bash`"
<FromGitter>
<codenoid> `
faustinoaq has quit [Ping timeout: 248 seconds]
ua__ has joined #crystal-lang
logen[m] has joined #crystal-lang
ua_ has quit [Ping timeout: 240 seconds]
csk157 has joined #crystal-lang
csk157 has quit [Ping timeout: 248 seconds]
faustinoaq has joined #crystal-lang
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 248 seconds]
aroaminggeek[awa is now known as aroaminggeek
aroaminggeek is now known as aroaminggeek[awa
rohitpaulk has joined #crystal-lang
csk157 has joined #crystal-lang
csk157 has quit [Ping timeout: 240 seconds]
csk157 has joined #crystal-lang
p0p0pr37 has quit [Remote host closed the connection]
p0p0pr37 has joined #crystal-lang
p0p0pr37 has quit [Changing host]
p0p0pr37 has joined #crystal-lang
p0p0pr37 has quit [Remote host closed the connection]
p0p0pr37 has joined #crystal-lang
p0p0pr37 has quit [Read error: Connection reset by peer]
p0p0pr37 has joined #crystal-lang
claudiuinberlin has joined #crystal-lang
aroaminggeek[awa has quit [Ping timeout: 248 seconds]
mbarbar has quit [Ping timeout: 260 seconds]
wyldcraft has joined #crystal-lang
alex`` has quit [Quit: WeeChat 1.9.1]
alex`` has joined #crystal-lang
<FromGitter>
<jjjaaayyy> pssst, there is a version 1.0 push coming
<FromGitter>
<codenoid> :O
<FromGitter>
<jjjaaayyy> rite?
wyldcraft has quit [Quit: Page closed]
<oprypin>
jjjaaayyy, what are you talking about....
<FromGitter>
<jjjaaayyy> "...progress towards a 1.0. We will be addressing some of the issues in these next few days and make an open call to help us fundraise for the final stretch." via email
<FromGitter>
<7sedam7> how can i help with development
<FromGitter>
<7sedam7> i’d like to contribute
<Papierkorb>
7sedam7, there's plenty to choose from in the issue tracker if you want to do anything
<oprypin>
jjjaaayyy, what are you talking about....
<Papierkorb>
jjjaaayyy, haven't received anything on the mailinglist
<FromGitter>
<codenoid> or in, crystal needed library
<oprypin>
jjjaaayyy, it is important that you explain very clearly what you mean. it's either the biggest news or the biggest scam
<FromGitter>
<7sedam7> thanks @Papierkorb
<FromGitter>
<jjjaaayyy> that was from Nicolas di Tada
<FromGitter>
<jjjaaayyy> he doesn't know me from Adam so i don't think it's a secret
<Papierkorb>
7sedam7, or you can, of course, contribute stuff that has no issue open but you think should be added to the project. If something in particular is grinding your gears, then that's usually a good thing to work on
<oprypin>
RX14, do u know anything about this
<oprypin>
jjjaaayyy, this is disturbing
<FromGitter>
<jjjaaayyy> whyfor
<RX14>
@jjjaaayyy where did you hear this?
<oprypin>
jjjaaayyy, why did you receive this email but most prominent members of the community didn't?
<RX14>
Ndt's recent talk?
<Papierkorb>
The last message from `Nicolas di Tada` on the ML was on October 9th as far I see. The message from Oct 5th mentions something on v1.0, but nothing I see directly implies getting fundings for that
<oprypin>
core member RX14 knows nothing about this
<FromGitter>
<jjjaaayyy> no, i just emailed him out of the blue offering to do some blog posts because some people on reddit were wondering if crystal was slowing down
<RX14>
Yeah well
<RX14>
I wouldn't put too much emphasis on that oprypin
<oprypin>
:|
<Papierkorb>
>_>;
<FromGitter>
<jjjaaayyy> i didn't receive any sort of announcement early, just a tip that they were going to be making some noise soon
<FromGitter>
<jjjaaayyy> which is cool
<oprypin>
all the more disturbing, really
<Papierkorb>
jjjaaayyy, then let's not make assumptions, or leak anything that may be still in a half baked state
<FromGitter>
<jjjaaayyy> isn't this sort of expected though?
<Papierkorb>
Maybe there's reason to celebrate, maybe there's not. I'll wait for an official announcement.
<FromGitter>
<jjjaaayyy> he told me that in an email that said yes please evangelize crystal however you can
<RX14>
oprypin, i can say they were talking about thinking of a fundraiser
<RX14>
but noting concrete since then
<RX14>
i would be extremely surprised that this was happening without anything being said in slack
<Papierkorb>
jjjaaayyy, evangelizing crystal is of course encouraged
<FromGitter>
<jjjaaayyy> a fundraiser is just an announcement, right? "hey, if you guys can raise X we are in a position to dedicate Y time toward version 1.0"
<RX14>
yeah but there's a lot of work into making that sound convincing
<Papierkorb>
I mean there's that .. open source funding thing going on, but that has been running for years
<Papierkorb>
(Links' in the topic for those wanting to chip in)
<RX14>
and my opinion is that relying on manas for anything more than their current level of commitment would be a mistake
<FromGitter>
<jjjaaayyy> version 1.0 is a marketing thing so managers will let developers use it
<RX14>
i'll be very happy if they do commit more resources in the future
<Papierkorb>
RX14: everyone will be
<RX14>
but until they do, it's best to work on the assumption that they won't
<FromGitter>
<jjjaaayyy> we've got to make it worth their while
<RX14>
1.0 is not a marketing thing lol
<FromGitter>
<jjjaaayyy> a lot of languages don't have any commercial backer
<RX14>
it's got a solid defined meaning under sember
<FromGitter>
<jjjaaayyy> i should look at that
<RX14>
semver*
<oprypin>
jjjaaayyy, languages that don't have any commercial backer are all even smaller than crystal
<RX14>
@jjjaaayyy after 1.0 we can't break any programs that currently compile until 2.0
<RX14>
that's what 1.0 means
<Papierkorb>
Then it's not all fun and games anymore :(
<oprypin>
if you use 2.0 willy-nilly then you can call 1.0 a marketing thing tho :p
<RX14>
it's a commitment to support programs written for 1.0 for years and years
<FromGitter>
<jjjaaayyy> acknowledged, i sort of regretted saying the marking line after i hit return
<RX14>
Papierkorb, heh well
<RX14>
i sort of disagree
<RX14>
we can certainly do what rust is doing I think
<FromGitter>
<jjjaaayyy> in *my* world it's a marketing thing because crystal is complete enough for my needs
<Papierkorb>
Well, hacks will work more reliably :)
<FromGitter>
<imonmyown> I like rust's scheduling method too
<FromGitter>
<jjjaaayyy> i didn't mean to create two controveries in a row
<Papierkorb>
RX14: besides windows, any idea on 0.24.1? Christmas present from manas?
<RX14>
look at the release PR
<RX14>
follow that
<RX14>
i wish we had someone else on the core team
<RX14>
i guess I shouldn't say that idk
<FromGitter>
<jjjaaayyy> i wish i were a little better at working on what's needed
<Vexatos>
RX14, just add me to core team, am crystal expert
<RX14>
if you don't count manas and jhass you have basically me and ysbaddaden
<oprypin>
RX14, it's all about the knowledge, not the status, anyway
<RX14>
Vexatos, inviting you here was a mistake
<Vexatos>
you didn't invite me
<RX14>
go away
<Vexatos>
hehe
<oprypin>
i'm basically out of the game
<RX14>
oprypin, you're very knowledgable about crystal
<oprypin>
i mean in a different way
<RX14>
you and Papierkorb are the people in this channel I would say know crystal the best
<RX14>
well, i mean discounting the core team
<FromGitter>
<bew> Agree
<oprypin>
lately i've just been hopelessly trying to sway Crystal away from ruby code smells
<oprypin>
i dont have time to do anything significant
<FromGitter>
<jjjaaayyy> rx14 what compilers had you worked on previously?
<RX14>
none
<RX14>
and I barely work on this one
<RX14>
I mainly work on the stdlib
<RX14>
and give my opinion from a non compiler developer on what the compiler should do
<FromGitter>
<jjjaaayyy> is there a separate issue tracker for that or is it moshed in with the rest?
<RX14>
not to say I don't understand how the compiler works in more detail than most
<RX14>
the issue tracker is for both
<FromGitter>
<jjjaaayyy> i like reinventing wheels - what's a category that needs attention?
<Papierkorb>
I don't think there's something lacking in particular. Best advice would be to look for rough edges that annoying you and try to improve that
<Vexatos>
That's basically the best thing to do
<Vexatos>
use the language
<Vexatos>
find stuff you don't like
<Vexatos>
fix it
<FromGitter>
<jjjaaayyy> hm peg has already been implemented twice
<FromGitter>
<jjjaaayyy> thrice
aroaminggeek has joined #crystal-lang
<FromGitter>
<jjjaaayyy> i don't even know the right question to ask about turning a PEG into a native binary instead using crystal as an interpreter
aroaminggeek has quit [Ping timeout: 240 seconds]
snsei has joined #crystal-lang
astronavt has joined #crystal-lang
csk157 has quit [Ping timeout: 240 seconds]
csk157 has joined #crystal-lang
<FromGitter>
<sdzyba> it feels like Crystal is going to be forked and continued by some more active people if Manas is really not going to return to at least maintaining the language, not even mentioning active development.
<RX14>
that doesn't make sense
<RX14>
there are people outside of manas who are on the core team and can approve PRs
<RX14>
if manas disappearsed we could still go on developing without a fork
<FromGitter>
<sdogruyol> now that all of the things
<FromGitter>
<sdogruyol> look what happened when I was away
<FromGitter>
<sdzyba> well, all I can see that there are a lot of awesome PRs out there and only relatively small are merged. ⏎ so I guess bigger ones are need some approval from Manas which is not happening so they're simply stale for months
<FromGitter>
<sdogruyol> @jjjaaayyy are you for real? If so I'd be happy to help you about evangelizing Crystal
<RX14>
@sdzyba me and ysbaddaden approving a PR means it's fine to merge - regardless of how big it is
<FromGitter>
<sdzyba> why they're not merged if so?
<RX14>
things always slip through the cracks
<RX14>
if you feel something should be merged but is waiting (for more than a week) then bump it
<oprypin>
sdzyba, currently there is no ideological congruency, nobody to take controversial decisions, and big PRs are usually controversial by their nature
<RX14>
but honestly I don't think ysbaddaden has a lot of time either
<RX14>
oprypin, yes thats probably a better point of view than mine
<oprypin>
but you're correct as well
<RX14>
perhaps the 2 people to merge thing was a mistake in some ways
<RX14>
arrgh
<RX14>
I wish we had a bdfl still
<FromGitter>
<sdzyba> still? you mean we had one?
<FromGitter>
<sdogruyol> @sdzyba yes, Ary
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
<FromGitter>
<imonmyown> @sdogruyol so he left after all? :(
<RX14>
currently
<FromGitter>
<sdogruyol> no, he's on a hiatus
<FromGitter>
<sdogruyol> he periodically does that
<FromGitter>
<imonmyown> you need to support him properly
<RX14>
@sdogruyol honestly, he's gone
<FromGitter>
<sdogruyol> I hope not :/
<FromGitter>
<imonmyown> some quantum shit going on
<RX14>
better than forcing him to work on a project he dislikes @sdogruyol
<FromGitter>
<jjjaaayyy> @sdogruyol wussuuuuuup
_whitelogger has joined #crystal-lang
<FromGitter>
<sdogruyol> @jjjaaayyy have we met before?
<FromGitter>
<sdogruyol> @RX14 I agree about not forcing anyone working on what they do not want
<FromGitter>
<jjjaaayyy> @sdogruyol @jjjaaayyy are you for real? If so I'd be happy to help you about evangelizing Crystal
<FromGitter>
<HCLarsen> I've already written my first Crystal tutorial on my blog.
aroaminggeek has joined #crystal-lang
alex`` has quit [Quit: WeeChat 1.9.1]
<FromGitter>
<jjjaaayyy> is anyone here familiar with why wasm isn't a compile target of interest?
<FromGitter>
<HCLarsen> I don't even know what wasm is, so I can't say.
<Papierkorb>
Because wasm isn't even production ready yet itself?
<Papierkorb>
Because the Crystal compiler has enough work to be done on itself without adding yet another thing to provide support for
<FromGitter>
<HCLarsen> Oh, it's short for Web Assembly.
<FromGitter>
<HCLarsen> With that in mind, I do like the idea of using Crystal for front end development, but Papierkorb's statement makes perfect sense.
<RX14>
@jjjaaayyy it's definitely a compile target of interest, it's nust not very practical for us to target right now
<FromGitter>
<jjjaaayyy> llvm can generate the code, right? is it just a matter of building DOM wrappers etc?
<Papierkorb>
You underestimate the effort needed to get it into a non-toy state
<Papierkorb>
You have to treat wasm as what it is: It provides completely new environment, it is in that moment the "operating system". You're asking to "just compile this to a entirely new OS"
snsei has quit [Remote host closed the connection]
<FromGitter>
<jjjaaayyy> so what happens if i tell llvm to target wasm instead of x86 for my .cr
<Papierkorb>
Try it?
snsei has joined #crystal-lang
<Papierkorb>
it probably compiles the instruction meant for x86_64-gnu-linux-unknown (or what you use) into wasm. If that goes through, it won't do much by itself
<FromGitter>
<jjjaaayyy> assuming that works, then the work is in building the browser bindings
<Papierkorb>
You need to provide it with the expected environment (mostly provided by glibc). If you get it to do that, you win.
<FromGitter>
<jjjaaayyy> i see!
<FromGitter>
<jjjaaayyy> that was the part i was missing
<Papierkorb>
Just keep in mind what I said.
<Papierkorb>
Also note that I oversimplified things.
<FromGitter>
<jjjaaayyy> i'm not afraid of the wasm virtual machine, but the glibc dependencies could be very hard
<FromGitter>
<jjjaaayyy> although i've sen glibc in javascript
<FromGitter>
<jjjaaayyy> well, if nobody knows these things, that means it's worth me poking at
snsei has quit [Ping timeout: 258 seconds]
<FromGitter>
<jjjaaayyy> i hate javascript so much i want to subplant it, not run on top of it like opal
<Papierkorb>
Mh? With Opal, you get almost all ruby goodies, while you can still fallback to JS where needed
<Papierkorb>
If they kept their pace they had when I used it ... 2.5 years ago or something .. then it should be actually quite amazing nowadays (It was already pretty good back then, still hat sime kinks but c'mon)
<FromGitter>
<jjjaaayyy> i despise javascript like an escaped convict despises the warden
<FromGitter>
<jjjaaayyy> i wish opal had been production ready before my last project
<FromGitter>
<jjjaaayyy> i wouldn't have touched js
<FromGitter>
<HCLarsen> ES6 makes JavaScript better than previous versions, but I'd still avoid it if I had other options for front end.
aroaminggeek is now known as aroaminggeek[awa
<RX14>
@jjjaaayyy you literally can't write a conservative GC in wasm
<RX14>
the only way Go runs on wasm is that it emulates all of it's stack operations, meaning it's very slow and buggy
<RX14>
it literally doesn't use the wasm stack, it writes custom code to perform the stack operations itself just so you can possibly maybe port the GC
<RX14>
wasm is nowhere NEAR ready for crystal
<RX14>
it's only ready for gcless languages
<RX14>
everything else is a hack
<FromGitter>
<jjjaaayyy> gotcha
aroaminggeek[awa is now known as aroaminggeek
aroaminggeek is now known as aroaminggeek[awa
aroaminggeek[awa is now known as aroaminggeek
<FromGitter>
<HCLarsen> gcless?
<oprypin>
HCLarsen, "without garbage collection"
<FromGitter>
<HCLarsen> Ahh, thank you.
rohitpaulk has quit [Ping timeout: 260 seconds]
rohitpaulk has joined #crystal-lang
<FromGitter>
<jjjaaayyy> i'm starting to use ruby/crystal/opal as a compile target
<FromGitter>
<HCLarsen> Ok, now that raises another question. My understanding of garbage collection comes from interpreted languages like Ruby, where the GC is part of the interpreter that de-allocates objects during runtime.
<FromGitter>
<HCLarsen> Since Crystal is a compiled language with no runtime engine, does that mean that the compiler inserts de-allocation commands into the compiled code based on analyzing the Crystal code?
<Papierkorb>
Then your understanding isn't really correct
<Papierkorb>
The interpreter and the GC are separate entities
<Papierkorb>
Neither does Ruby analyze the code to figure out when to deallocate something, nor does Crystal
<Papierkorb>
The only language doing that (to the best of my knowledge) to the full extend, and thus not relying on a GC at all, is Rust
<FromGitter>
<HCLarsen> Ok. So does the GC operate during runtime, or not?
<Papierkorb>
yes, of course.
<FromGitter>
<HCLarsen> Even in compiled languages?
<Papierkorb>
Memory management comes at a price. Manually done like in C, it puts the burden on the developer (who can simply forget). Automatic, it's done at runtime. Half-Automatic, like in Rust, it burdens the developer while the compiler enforces the rules.
<Papierkorb>
Yes of course, how do you expect the compiler to figure the correct thing out in 100% of all cases?
<Papierkorb>
It can't. You only have to look at how you have to tell Rust about object lifecycles
<Papierkorb>
Because even Rust can't do it entirely by itself. Those markers aren't for the dev, they're for the compiler.
<FromGitter>
<HCLarsen> Ok, so when I've compiled a Crystal program, and then run it later, there's still a GC running in a separate process to manage the memory?
<Papierkorb>
Why in a separate process?
<Papierkorb>
In the same
<Papierkorb>
And yes, of course
<Papierkorb>
Just as in Go. Just as in D. Just as in Java.
<FromGitter>
<HCLarsen> I've never used Go or D, and my Java knowledge is limited.
<FromGitter>
<HCLarsen> But I do know that Java bytecode runs in the JVM. My understanding is that Crystal compiles down to assembly code and runs completely natively?
<Papierkorb>
Yes .. so?
<FromGitter>
<HCLarsen> So the GC is included in that compiled file?
<Papierkorb>
JVM Bytecode isn't that much different from "real" machine code. In fact, it can be, as there are literally embedded systems running java bytecode as native code.
<FromGitter>
<HCLarsen> Cool.
<Papierkorb>
We use the BoehmGC, which is commonly linked dynamically. that's `libgc.so`
<RX14>
@HCLarsen the GC doesn't work by working out what to delete
<RX14>
it works out what not to delete
<RX14>
and deleting everything else
rohitpaulk has quit [Ping timeout: 248 seconds]
<RX14>
thus you can't "insert free calls" because thats simply the wrong way to look at what a GC does
<FromGitter>
<HCLarsen> Ok.
<RX14>
it starts with a number of "roots", which are objects which the GC knows that the program can reach
<RX14>
i.e. the contents of the callstack
DTZUZO has joined #crystal-lang
<RX14>
and the registers
<FromGitter>
<HCLarsen> Reference counting?
<RX14>
then it keeps following pointers until there are no pointers to follow
<Papierkorb>
?
<Papierkorb>
Boehm doesn't do ref counting
<RX14>
no @HCLarsen
<RX14>
refcounting is entirely seperate
<FromGitter>
<HCLarsen> Ok, no reference counting.
<RX14>
the objects that it finds by following pointers are thus the ones the program can access
<RX14>
these objects are marked
<RX14>
everything else gets removed
<FromGitter>
<HCLarsen> Ok. Then it deletes anything not marked.
<Papierkorb>
(That's called "Mark and Sweep" btw)
<FromGitter>
<HCLarsen> Ok, got it.
<FromGitter>
<unreadable> oh boehmgc, delete was too mainstream
<RX14>
thats not boehm
<RX14>
thats how all gcs ever worked
<Papierkorb>
Yeah because no one ever forgot to put an explicit free()
<Papierkorb>
Or put one too many
<FromGitter>
<HCLarsen> So, this libgc.so, that file would have to be on any machine for it to run a compile Crystal program?
<Papierkorb>
Or one too early
<Papierkorb>
HCLarsen, yes
<FromGitter>
<jjjaaayyy> real programmers don't need dynamic memory allocation
<Papierkorb>
Real programms don't need high level programming languages either, assembly is fine by itself
<Papierkorb>
If you have unlimited time resources, that is
<RX14>
real programmers also dont exist
<FromGitter>
<HCLarsen> I'll take assembly over JavaScript. It was easier to learn.
<FromGitter>
<jjjaaayyy> and it's friggin consistent
<Papierkorb>
If you only have limited time, then maybe a little help of the machine isn't too bad of a compromise
<RX14>
if you have unlimited time you don't need a computer
<RX14>
all you need is pen and paper
<FromGitter>
<jjjaaayyy> nasa coding guidelines discourage malloc
<Papierkorb>
RX14: Wait, you're not too lazy to do that?
<FromGitter>
<jjjaaayyy> pens run out, use pebbles
<FromGitter>
<unreadable> where can I crack a java to machine code compiler..for learning purpose
<RX14>
i'm also too lazy for free() Papierkorb
<FromGitter>
<unreadable> bytecode*
<Papierkorb>
Me too thanks
<FromGitter>
<jjjaaayyy> @unreadable why a vm language?
<FromGitter>
<unreadable> bytecode to machine code
<FromGitter>
<HCLarsen> I remember writing code on paper back in college.
<RX14>
@unreadable gccj
<FromGitter>
<jjjaaayyy> "as difficult to reverse engineer as if they were written in C++." should read "as difficult to read as C++"
<FromGitter>
<unreadable> unmantained
<RX14>
ops
<RX14>
gcj
<FromGitter>
<unreadable> or better said abandoned
<RX14>
ok
<RX14>
wonder why
<RX14>
oh wait because it's dumb
<FromGitter>
<unreadable> congratz 😄
<FromGitter>
<unreadable> $3000 for a compiler, sweat
<FromGitter>
<unreadable> or transpiler
<RX14>
transpilers dont exist
<FromGitter>
<HCLarsen> Babel's a transpiler.
<FromGitter>
<unreadable> oh, it should've been *sweet. There's some js transpilers, I was misunderstanding
<RX14>
no its not
<RX14>
its a compiler
<RX14>
transpiler is a dumb word for a compiler
<FromGitter>
<HCLarsen> There's a specific difference between the two.
<RX14>
not really
<RX14>
not technically
<FromGitter>
<HCLarsen> A transpiler translates code into another language of the same level, whereas compilers translate code from a higher level language to a lower level language.
DTZUZO has quit [Ping timeout: 240 seconds]
<RX14>
I disagree
<RX14>
there's no real distinction in techniques between the two
<RX14>
even if you want to define "transpiler", they're just a subset of compilers
<FromGitter>
<HCLarsen> Maybe not in techniques, but a clear distinction in what they're used for.
<RX14>
i disagree too
<RX14>
they're all used for taking code in one language and outputting it in something runnable
sz0 has quit [Quit: Connection closed for inactivity]
<FromGitter>
<HCLarsen> So, that doesn't change the truth of my earlier statement: A transpiler translates code into another language of the same level, whereas compilers translate code from a higher level language to a lower level language.
<FromGitter>
<HCLarsen> They're used in different cases, which is why a distinction in the name needs to be made.
<RX14>
but the only reason they're different is because you made the distinction in the first place
<RX14>
they're different because they translate between high-level and high-level
<RX14>
but then thats how you defined them?
<FromGitter>
<HCLarsen> That's how languages have been defined for a very long time. Probably longer than I've been alive.
<FromGitter>
<jjjaaayyy> x86 machine code hasn't been "bare metal" itself for years, what with pipelining and microcode
<FromGitter>
<HCLarsen> Compilers have always been used to take a higher level language, and translate it into a lower level language, so when they came across the idea to translate into a language at the same level, they had to come up with a new name. It's perfectly logical.
<FromGitter>
<unreadable> I'd say so about the definition of a transpiler, but who cares, life is too short. I'm thankful that it made my work easier so I'm just gonna use it when need, but it's just another dumb tool
<FromGitter>
<unreadable> js is full of these
<FromGitter>
<HCLarsen> In any case, I gotta split.
<FromGitter>
<alehander42> a lot of people don't agree with the "transpiler" definition, I tend to agree as if you start on this path, you have to add a word for every situation
<FromGitter>
<alehander42> eg how do you call a compiler from a low-level lang to a higher-level lang?
<Papierkorb>
decompiler, or in practice, disassembler
vivus has joined #crystal-lang
<RX14>
Papierkorb, java decompilers are typically not called disassemblers
<Papierkorb>
sure, just pointed at that disassemblers are more common than full decompilers
<RX14>
but the techniques for writing a disassembler are largely different than to the ones for writing a compiler
<RX14>
there's no lex/parse/ast/whatever
<RX14>
for both compiler and "transpilers" there almost always is
<RX14>
and besides, transpilers typically translate higher level concepts into lower level ones
<RX14>
typescript typically compiles to es3 or es6
<RX14>
both of which are lacking features it lacks
<RX14>
so in the end it has to compile those new features it presents over es6 into the output
DTZUZO has joined #crystal-lang
<FromGitter>
<alehander42> I don't agree
<FromGitter>
<alehander42> there *is* parsing and traversing, just the binary format is usually trivial to parse
<FromGitter>
<alehander42> and the result is usually a list, not a tree
<FromGitter>
<alehander42> in principal, it's still a similar architecture
<FromGitter>
<alehander42> principle*
faustinoaq has quit [Ping timeout: 248 seconds]
DTZUZO has quit [Ping timeout: 248 seconds]
daemonwrangler has quit [Quit: ZNC 1.6.5 - http://znc.in]