<|jemc|>
chrisseaton: I'm guessing github doesn't render them right and that's what the line just above is about - "The documentation is best viewed on the documentation website."
<mustmodify>
I just wanted to say thanks again for the help with that Psych issue. It was really kicking my ass an I'm happy to be able to use Rubinius in production now. I should be switching over to the new server this coming week.
<brixen>
mustmodify: sweet!
<brixen>
mustmodify: sorry, didn't realize you were struggling with it for so long
<brixen>
we need some protocol for people to indicate they are blocked on production issues vs just trying out rbx
bakkdoor has joined #rubinius
<mustmodify>
brixen: no need to be sorry, I didn't raise the red flag of disaster because I couldn't pinpoint the issue. I just new that gems weren't working... so it was hard to blame psych at that point. :)
<mustmodify>
s/new/knew
<brixen>
yeah, it can be confusing
Liothen has joined #rubinius
<yorickpeterse>
brrr, Java
havenwood has joined #rubinius
houhouli_ has quit [Remote host closed the connection]
havenwood has quit [Remote host closed the connection]
<yorickpeterse>
and we don't even do continuous delivery actually
<yorickpeterse>
"mostly-continuous-delivery" as I call it, since it still requires a manual button press
<yxhuvud>
I don't even see how continous delivery could make sense in our business as our customers tend to want to do a lot of (mostly manual) testing before going into production. There are systems that take months or even years before that happen..
|jemc-bot| has quit [Ping timeout: 246 seconds]
havenwood has joined #rubinius
|jemc-bot| has joined #rubinius
diegoviola has joined #rubinius
|jemc-bot| has quit [Remote host closed the connection]
jc00ke has quit [Ping timeout: 272 seconds]
dlackty__ has quit [Ping timeout: 245 seconds]
mjc_ has quit [Ping timeout: 276 seconds]
cezarsa has quit [Ping timeout: 276 seconds]
mustmodify has left #rubinius [#rubinius]
<brixen>
yxhuvud: continuous delivery doesn't dictate where the release goes to
<brixen>
that stuff being manually tested is a kind of release
Thijsc has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
diegoviola has quit [Remote host closed the connection]
max96at is now known as max96at|off
dlackty__ has joined #rubinius
Bwild has quit [Ping timeout: 256 seconds]
<cremes>
yorickpeterse: hey, can you forward me the articles you found when researching racc? i need to do some racc work for the ffi-io branch but i’ve never done anything with it before, so i need some examples & tutorials if you found any.
<cremes>
so far i found only one written by tenderlove showing how to do a json parser.
<cremes>
pretty good but lots of hand waving about how the pieces all fit together, what needs to be written versus generated, etc.
<cremes>
as a sneak peek as to why i need this, i am trying to convert the “stat” function to pure FFI. it reads and dumps a bunch of
<brixen>
the problem with stat is that it's usually a macro
<brixen>
find the actual symbol in libc to bind is hard
<cremes>
information into a C struct. so far that’s pretty easy to support by manually writing the FFI::Struct stuff, but that struct differs between OSes.
<cremes>
i want to run the output from gcc -E <header> through a racc parser and auto-generate the FFI::Struct for each platform.
<cremes>
brixen: not a macro on osx. is it a macro on linux?
<brixen>
uh, we already do that
<brixen>
'stat' is often a macro
<cremes>
brixen: i’m ready to be proven wrong, but i don’t see how to do that from the ffi2-generators project.
<cremes>
when using that proj to generate structs, you need to know the field names in advance. they differ between platforms.
<cremes>
to discover them at build time you need to parse the header. the project doesn’t do that. it just parses the header to figure out sizes and offsets using the “fields” hand-coded in the header.rb.ffi file.
<brixen>
also nm bin/rbx | ack '\s_stat' => U _stat$INODE64
<cremes>
brixen: okay, i see that. but note what i said above… you need the code to name each field along with giving its type, e.g. “s.field :st_nlink, :nlink_t”
<cremes>
wouldn’t it be better to point a program at “sys/stat.h” and say, generate the FFI::Struct from the header without giving any more instructions?
<brixen>
indeed
<brixen>
yes, that would be great
<brixen>
I'd suggest looking at clang
<brixen>
if there's an API we can use, we can build that machinery
cezarsa has joined #rubinius
<cremes>
for example, the stat structure on osx has different fields and in a different order from linux (i checked). you need to do all that if/else bullshit to cover all the bases.
<brixen>
you'll be hard-pressed to find more garbage in libc than stat
<cremes>
yeah, clang has -E support too. i’ve started looking at the ANSI C lex/yacc stuff that already knows how to parse out structs & unions from headers.
<brixen>
believe me, I've tread that path plenty
<brixen>
I meant, clang as in library, not cli
<cremes>
if i can build a parser out using those *.y files it would get aus a long way toward the goal.
<cremes>
ah, i see.
<brixen>
clang/llvm
<cremes>
is the lex/yacc direction fruitless as in you couldn’t get it to work?
<brixen>
well, first of all, use kpeg if you want a parser
<brixen>
I don't want racc in anything rbx-related
<cremes>
ok, happy to use whatever
<brixen>
second, I'd leave stat to the very end
<cremes>
third?
<brixen>
it is such a pile of pain that I'm seriously considering a stat instruction
<brixen>
third, profit, of course :)
<cremes>
heh
<brixen>
is there not a POSIX syscall for stat-like functionality?
<brixen>
I'd rather implement that and avoid libc completely, if possible
<cremes>
according to osx “man -s 2 stat” the stat and fstat calls are POSIX.1 requirements
<brixen>
apparently, they couldn't standardize the stat struct, though? :p
<cremes>
nope
<cremes>
i suppose i could punt this issue down the road and just hand-code the stat struct depending on the platform using the usual if/else magic.
<cremes>
but generating the structs directly from the header seems tantalizingly close…
* cremes
reads up on evanphx/kpeg
<brixen>
cremes: why do you need something other than what's already in Rubinius::Config?
<cremes>
maybe i don’t. i’ll need to look at that file closer.
<cremes>
i can shelve this other stuff until later. sure would be nice to offer some more bells & whistles for ffi2-generators.
<cremes>
i gotta go to the in-laws for dinner, so i’ll look at the platform.rake file more closely later tonight or tomorrow.
<brixen>
cremes: ok, cool
<cremes>
brixen: rubinius is a big project with lots of nooks and crannies. still discovering things. :)
<brixen>
cremes: heh, indeed
jc00ke has joined #rubinius
|jemc| has quit [Quit: WeeChat 1.0.1]
awsteele has joined #rubinius
meh` has quit [Quit: reboot]
meh` has joined #rubinius
|jemc| has joined #rubinius
awsteele has quit [Quit: My Mac has gone to sleep. ZZZzzz…]