Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 00:05
    beta-ziliani closed #12166
  • Jun 28 21:21
    straight-shoota milestoned #12155
  • Jun 28 21:11
    beta-ziliani milestoned #12156
  • Jun 28 20:47
    straight-shoota closed #12163
  • Jun 28 20:47
    straight-shoota closed #12162
  • Jun 28 20:47
    straight-shoota closed #11773
  • Jun 28 20:47
    straight-shoota closed #11732
  • Jun 28 20:47
    straight-shoota closed #11872
  • Jun 28 20:46
    straight-shoota milestoned #12026
  • Jun 28 20:46
    straight-shoota demilestoned #12026
  • Jun 28 20:38
    beta-ziliani milestoned #12165
  • Jun 28 20:30
    beta-ziliani synchronize #12146
  • Jun 28 19:40
    beta-ziliani edited #5430
  • Jun 28 18:51
    beta-ziliani opened #12166
  • Jun 28 18:51
    beta-ziliani labeled #12166
  • Jun 28 08:54
    straight-shoota closed #12158
  • Jun 28 08:54
    straight-shoota closed #12141
  • Jun 28 08:54
    straight-shoota closed #12123
  • Jun 28 08:54
    straight-shoota closed #3835
  • Jun 28 08:54
    straight-shoota closed #12094
From IRC (bridge bot)
@FromIRC
<yxhuvud> Not really an option for mmap.
Ali Naqvi
@naqvis
just looked into mmap manpage :P
@didactic-drunk you can do a comparison against Pointer(Void).new(-1)
Quinton Miller
@HertzDevil
for the record, that constructor calls -1.to_u64!
Ali Naqvi
@naqvis
Quinton Miller
@HertzDevil
well since crystal always maps Void to Nil you can "dereference" any Pointer(Void) and it'll be nil
0xffff_ffff_ffff_ffff is definitely -1.to_u64!
Ali Naqvi
@naqvis
but isn't Pointer(Void).new(-1) equivalent to C (void *) -1?
Quinton Miller
@HertzDevil
iso c says nothing about the size of a void*
crystal more or less defines the pointer size to always be 8 bytes
From IRC (bridge bot)
@FromIRC
<yxhuvud> hertzdevil: not only that, iso c doesn't even define what the value of a null pointer actually is.
Quinton Miller
@HertzDevil
0 is definitely not a null pointer on cc65 targetting the nes
Ali Naqvi
@naqvis

test.c

void* test() {
  return ((void *) -1);
}

test.cr

@[Link(ldflags: "-L#{__DIR__}/ -ltest.o ")]
lib Test
  fun test : Void*
end

p! Test.test == Pointer(Void).new(-1) # => true
Quinton Miller
@HertzDevil
that's due to the abi, not the c standard
Ali Naqvi
@naqvis
yeah true, but this does answer the original question on how to find out if mmap failed
Quinton Miller
@HertzDevil
it will break silently if c's void* is smaller than crystal's Pointer(Void) and zero extension is performed instead of sign extension
Ali Naqvi
@naqvis

https://man7.org/linux/man-pages/man2/mmap.2.html

On error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno is set to indicate the error.

Quinton Miller
@HertzDevil
what's doable is still doing that and then comparing your pointer to the return value of test instead
and not to a Pointer(Void) created in crystal
for portability
Ali Naqvi
@naqvis
but invoking FFI, crystal is yielding the same result as it do for Pointer(Void)
p! Test.test # => Pointer(Void)@0xffffffffffffffff
is crystal doing some conversions behind the scenes?
didactic-drunk
@didactic-drunk
I think 0x0 is a valid mapping/success return value for mmap so -1 is used.
Ali Naqvi
@naqvis
yeah, make sense
didactic-drunk
@didactic-drunk
Will Pointer(UInt8).new(-1) end up optimized to a constant single value or should I store a copy for comparison?
Ali Naqvi
@naqvis
should be same for each invocation
as we are giving the same address
but for easy maintenance, better to have constant defined like MMAP_FAILED
Thore Bödecker
@foxxx0
Hi, I'm trying to spawn a long-running process in the background that occasionally prints something on stdout. i want to have that Fiber blocking until the next line on stdout, which works fine using #gets on the stdout pipe. however, as soon as this fiber is part of my multi-fiber application, the other fibers seem to be blocked too
source code with the problematic fiber highlighted: https://paste.foxxx0.de/ngH/crystal#n101
didactic-drunk
@didactic-drunk
Is it possible to have multiple flags type params filled using symbols? https://carc.in/#/r/bbk7
George Dietrich
@Blacksmoke16
@didactic-drunk https://carc.in/#/r/bbkt
best you can do atm, see crystal-lang/crystal#10680
Jonathan Silverman
@mixflame
my scalablepress/paypal/gbaldraw integration is live
another store
you can order the collab canvas prints on shirts and other products now
https://gbaldraw.fun/ please bear in mind the content on the global/empty string room is user generated by anonymous users, apologies if you see anything triggering, if that's the case, please click the link on the right instead and create your own (infinitely lasting) private room
the global room is popular with free speech exhibitionists, please excuse me for that
running Amber on Crystal 1.0.0
ported from Rails 6/Ruby 3
(code is original and by me)
except in places where it's not
didactic-drunk
@didactic-drunk
@yxhuvud @naqvis @HertzDevil thank you for the pointer help making mmap.cr possible.
From IRC (bridge bot)
@FromIRC
<postmodern> didactic-drunk , cool i didn't know there was a crystal-posix project. I had to create https://github.com/postmodern/ioctl.cr to get access to the Linux kernel's specialized ioctls (v4l2).
didactic-drunk
@didactic-drunk

crystal-posix started when @chris-huxtable and I had design differences with the core team. Sometimes we need native types exposed rather than Int32 everywhere. The largest disagreement was on compile time vs runtime safety. @astterite wants everything to compile cross platform without macros or if respond_to? checks. An acceptable workaround to him is platform_specific_method may raise an error on an unsupported platform (but it still compiles - I haven't figured out why that matters if it doesn't work). We've chosen

{% if supported_platform %}
  def platform_specific_method
{% end %}

Then letting the code break when compiling if you don't check with respond_to. This let's you know something will or won't work when compiling rather than having random breakage you may or may not test for.

The whole argument can probably be summed in 2 + 1 posts.

From IRC (bridge bot)
@FromIRC
<postmodern> @didactic-drunk, couldn't you do the standard {% if supported %} .. {% else %} {% error(...) %} pattern that C/C++ uses for compile time compatibility checks
didactic-drunk
@didactic-drunk
My message describes one example. I think we tried 3 or more different solutions but crystal would only accept "compiles everywhere, runs uncertainly". An example would be the windows sid. Process.sid should work on windows only. With the official crystal way it's a runtime error when called. With our if you call it on a non windows system the program won't compile. I think that fits better with the crystal philosophy of "Crystal is statically type checked, so any type errors will be caught early by the compiler rather than fail on runtime." (taken from crystals web page).
Also, how do you know what a supported platform is and should you need to know for every API. Feature checking with respond_to allows for future proofing. Example: Linux supports open45, later FreeBSD adds support, and finally Mac/OS 15 years later. The shard wrapping open45 can add os support incrementally while every crystal program using the shard can keep the same feature check without changing their code, just update to a new shard for new os support.
From IRC (bridge bot)
@FromIRC
<postmodern> hmm yeah, handling platform-specific code vs. platform agnostic code will eventually become a problem