<FromGitter>
<stellarpower> It looks like it's missing...
<spuun>
Guessing here, but just use 115200 as value instead of the enum?
<spuun>
speed_t is a typdef for unsigned int
<FromGitter>
<stellarpower> It's an actual enum, the values start at 0 and go up by one
<FromGitter>
<stellarpower> Unfortunately
<spuun>
What method are you invoking to set baud rate?
<FromGitter>
<stellarpower> > UNIX V7 and several later systems have a list of baud rates where after the values B0 through B9600 one finds the two constants EXTA, EXTB ("External A" and "External B"). Many systems extend the list with much higher baud rates.
<FromGitter>
<stellarpower> That could be an issue
<FromGitter>
<stellarpower> Was following the sample in the readme. I'll try a different library, but maybe the Termios lib needs expansion(?) as I think a lot of Arduino projects use 112500
<straight-shoota>
I think that termios module is completely unmaintained. Not even sure why it's in stdlib
<FromGitter>
<stellarpower> Ah, okay
<FromGitter>
<stellarpower> I always find this frustrating. It's been nearly three years I've been wantingto learn crystal, but I don't have the time to sit down and do it just on its own. But every time I have a project that I could use it for, I just can't progress because there aren't enough maintained/high-quality shards to do what I need to do, so it has to go back on the pile :(
<FromGitter>
<Dan-Do> > *<Yxhuvud>* asking cause I'm trying to link to a c-lib with a bunch of functions defined as `static inline` which the linker doesn't seem to find. Perhaps it could be related to my problem :D ⏎ ⏎ Hope that this will be documented on the reference site. It took me 1 day searching around before getting this :(
<FromGitter>
<stellarpower> I didn't know C supported inlining
<FromGitter>
<Dan-Do> > *<Yxhuvud>* ( for reference, I'm experimenting with creating bindings for https://github.com/axboe/liburing ) ⏎ ⏎ How is thing going with this? I am willing to try it.
<xyhuvud>
hmm. I wonder why `Enumerable#index` is nilable and doesn't have a nilable variant like `Enumerable#index?`.
<xyhuvud>
dan-do: The bindings can be found at github.com/yxhuvud/ior. What isn't yet in working order is integration with the crystal event loop.
<straight-shoota>
yxhuvud: You can just use index(x).not_nil! for that
<straight-shoota>
I think it's nilable because index is a search method and you should never expect a search to be successful.
<xyhuvud>
straight-shoota: I know. But I hate having to use not_nil!. :)
<f1refly>
what pastebin that supports crystal would you guys recommend?
<straight-shoota>
then do index(x) || raise IndexError.new("couldn't find x")
<xyhuvud>
I know how to solve it. I just find it inconvenient that it breaks the normal pattern.
<straight-shoota>
There is a pattern that some methods have a nilable `?` variant, but it doesn't apply everywhere
<straight-shoota>
I wouldn't call it "normal pattern"
<straight-shoota>
there's also the similar pattern that methods define a non-nilable `!` variant
<xyhuvud>
true. neither exist for find or index. (though find has an extra argument that allows a fallback)
<straight-shoota>
that extra arg exists because just `nil` could be an actual result of find. For index, that's unnecessary because nil can't be a valid result
<xyhuvud>
It is not unnecessary, as the lack of it forces me to massage the code to make the type checker happy.
<straight-shoota>
?? if you want a default value for index, just do `index(x) || default_value`
<xyhuvud>
well I'd prefer it to raise..
<straight-shoota>
Again, both index and find are search methods where you shouldn't expect to get a result.
<xyhuvud>
That make no sense. That is *totally* dependent on use case.
<straight-shoota>
Yeah I guess index! could be a useful addition for use cases where you're sure the value exists and just want to find its position
<straight-shoota>
I'll approve a PR for that
<xyhuvud>
find! too?
wolfshappen has quit [Ping timeout: 252 seconds]
wolfshappen has joined #crystal-lang
<straight-shoota>
Yeah, probably makes sense
<xyhuvud>
<3
<FromGitter>
<asterite> Also `next!` for `Iterator`, to raise on `Stop` instead of getting a union type
<straight-shoota>
Yeah. That should be a different feature, though
szutt has quit [Quit: Client closed]
szutt has joined #crystal-lang
yxhuvud has joined #crystal-lang
xyhuvud has quit [Ping timeout: 268 seconds]
szutt has quit [Quit: Client closed]
szutt has joined #crystal-lang
dmgk has joined #crystal-lang
szutt has quit [Quit: Client closed]
dostoyevsky2 has quit [Ping timeout: 268 seconds]
pusewic|away_ has quit [Ping timeout: 264 seconds]
pusewic|away_ has joined #crystal-lang
casionaut has joined #crystal-lang
<antoszka>
Guys, I'm running crystal for `aarch64` from `brew.sh` and I'm seeing a ton of such warnings `ld: warning: dylib (/opt/homebrew/lib/libpcre.dylib) was built for newer macOS version (12.0) than being linked (11.3)`
<antoszka>
Whenever I run the crystal program I started developing a while ago.
<antoszka>
(removing `~/.cache/crystal` does not change anything)
<FromGitter>
<maxfierke> try `brew reinstall pcre`? that should give version compiled for whatever macOS you're running
<FromGitter>
<maxfierke> or `brew reinstall crystal`, if that was compiled for 11.3 originally
casionaut has left #crystal-lang [o7]
<antoszka>
I just purged all of my brew and reinstalled from scratch, so that's not the issue...
<antoszka>
Other type of warnings look this way `ld: warning: object file (P-roc40N-il41.o) was built for newer macOS version (12.0) than being linked (11.3)`
<antoszka>
Without any specific path — I can't find files on the filesystem looking like those mangled names/symbols.
<FromGitter>
<maxfierke> you may need to update xcode? Possible your machine is still using the SDK that is targeting 11.3 whereas the homebrew-built libraries are targeting 12.0
<FromGitter>
<maxfierke> `xcode-select --install` is hopefully enough, but sometimes you have to completely remove the xcode developer tools and reinstall to get it to pull in the new version properly