gmane.comp.lang.factor.general

Joe Groff | 31 Aug 19:50

<CFNumber> still references c-types at runtime in deployed image. Not sure why

I was trying to deploy an image, and the resulting app is bombing out  
with a "no-c-type" exception inside a call to <CFNumber>. Now it's no  
big deal to switch on "deploy-c-types?", but looking at the definition  
of <CFNumber> in core-foundation, it seems like it shouldn't need the  
c-types at runtime:

GENERIC: <CFNumber> ( number -- alien )
M: integer <CFNumber>
     [ f kCFNumberLongLongType ] dip <longlong> CFNumberCreate ;
M: float <CFNumber>
     [ f kCFNumberDoubleType ] dip <double> CFNumberCreate ;
M: t <CFNumber>
     drop f kCFNumberIntType 1 <int> CFNumberCreate ;
M: f <CFNumber>
     drop f kCFNumberIntType 0 <int> CFNumberCreate ;

Is there something here I'm missing that prevents the optimizing  
compiler picking out the <c-object> calls? Calling infer on each  
method definition gives the expected (( object -- object )), and "core- 
foundation" reload doesn't emit any warnings or errors.

-Joe

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

headers

Slava Pestov | 31 Aug 22:36

Re: <CFNumber> still references c-types at runtime in deployed image. Not sure why

Hi Joe,

I know about this. As a workaround, enable 'retain C types' in the deploy tool.

The problem is that code like "int" heap-size isn't constant-folded, because folding of calls to generic words is broken. There will be a fix coming up shortly.

Slava

On Sun, Aug 31, 2008 at 12:51 PM, Joe Groff <arcata-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

I was trying to deploy an image, and the resulting app is bombing out
with a "no-c-type" exception inside a call to <CFNumber>. Now it's no
big deal to switch on "deploy-c-types?", but looking at the definition
of <CFNumber> in core-foundation, it seems like it shouldn't need the
c-types at runtime:

GENERIC: <CFNumber> ( number -- alien )
M: integer <CFNumber>
[ f kCFNumberLongLongType ] dip <longlong> CFNumberCreate ;
M: float <CFNumber>
[ f kCFNumberDoubleType ] dip <double> CFNumberCreate ;
M: t <CFNumber>
drop f kCFNumberIntType 1 <int> CFNumberCreate ;
M: f <CFNumber>
drop f kCFNumberIntType 0 <int> CFNumberCreate ;

Is there something here I'm missing that prevents the optimizing
compiler picking out the <c-object> calls? Calling infer on each
method definition gives the expected (( object -- object )), and "core-
foundation" reload doesn't emit any warnings or errors.

-Joe

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Factor-talk mailing list
Factor-talk-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/factor-talk

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Factor-talk mailing list
Factor-talk@...
https://lists.sourceforge.net/lists/listinfo/factor-talk

headers

Slava Pestov | 1 Sep 02:27

Re: <CFNumber> still references c-types at runtime in deployed image. Not sure why

Hi Joe,

This problem has been fixed. I have tested the deploy tool with a few simple examples and the unit tests pass. Let me know if you have any other problems.

Slava

On Sun, Aug 31, 2008 at 12:51 PM, Joe Groff <arcata-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

I was trying to deploy an image, and the resulting app is bombing out
with a "no-c-type" exception inside a call to <CFNumber>. Now it's no
big deal to switch on "deploy-c-types?", but looking at the definition
of <CFNumber> in core-foundation, it seems like it shouldn't need the
c-types at runtime:

GENERIC: <CFNumber> ( number -- alien )
M: integer <CFNumber>
[ f kCFNumberLongLongType ] dip <longlong> CFNumberCreate ;
M: float <CFNumber>
[ f kCFNumberDoubleType ] dip <double> CFNumberCreate ;
M: t <CFNumber>
drop f kCFNumberIntType 1 <int> CFNumberCreate ;
M: f <CFNumber>
drop f kCFNumberIntType 0 <int> CFNumberCreate ;

Is there something here I'm missing that prevents the optimizing
compiler picking out the <c-object> calls? Calling infer on each
method definition gives the expected (( object -- object )), and "core-
foundation" reload doesn't emit any warnings or errors.

-Joe

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Factor-talk mailing list
Factor-talk-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/factor-talk

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Factor-talk mailing list
Factor-talk@...
https://lists.sourceforge.net/lists/listinfo/factor-talk

headers

Joe Groff | 1 Sep 03:35

Re: <CFNumber> still references c-types at runtime in deployed image. Not sure why

On Aug 31, 2008, at 5:27 PM, Slava Pestov wrote:

> Hi Joe,
>
> This problem has been fixed. I have tested the deploy tool with a  
> few simple examples and the unit tests pass. Let me know if you have  
> any other problems.

Man, what service! Thanks, Slava. I tried deploying a few demos, and  
they started up fine. For some reason, though, the "spheres" demo  
won't react to key or mouse gestures when deployed. Could the gesture  
map set up by "set-gestures" be getting thrown out by the tree shaker?  
Here's my deploy.factor for the vocab:

-- 8< --
USING: tools.deploy.config ;
H{
     { deploy-name "spheres" }
     { deploy-io 2 }
     { deploy-word-defs? f }
     { deploy-c-types? t }
     { deploy-random? t }
     { deploy-word-props? f }
     { deploy-reflection 1 }
     { deploy-threads? t }
     { deploy-math? t }
     { "stop-after-last-window?" t }
     { deploy-ui? t }
     { deploy-compiler? t }
}
-- 8< --

-Joe

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

headers

Joe Groff | 1 Sep 03:39

Re: <CFNumber> still references c-types at runtime in deployed image. Not sure why

On Aug 31, 2008, at 6:35 PM, Joe Groff wrote:

> On Aug 31, 2008, at 5:27 PM, Slava Pestov wrote:
>
>> Hi Joe,
>>
>> This problem has been fixed. I have tested the deploy tool with a  
>> few simple examples and the unit tests pass. Let me know if you  
>> have any other problems.
>
> Man, what service! Thanks, Slava. I tried deploying a few demos, and  
> they started up fine. For some reason, though, the "spheres" demo  
> won't react to key or mouse gestures when deployed. Could the  
> gesture map set up by "set-gestures" be getting thrown out by the  
> tree shaker? Here's my deploy.factor for the vocab:

I looked at it further, and that's exactly what's happening. set- 
gestures sets a word property on the class whose gestures are being  
set, so the deploy.factor needed { deploy-word-props? t } set to  
preserve the gesture map. With that set, spheres reacts to the mouse  
like a champ. Unfortunately, the deployed size jumps almost three  
times (from 5MB to 13MB).

-Joe

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

headers

Slava Pestov | 1 Sep 09:53

Re: <CFNumber> still references c-types at runtime in deployed image. Not sure why

On Sun, Aug 31, 2008 at 8:35 PM, Joe Groff <arcata@...> wrote:
> I tried deploying a few demos, and
> they started up fine. For some reason, though, the "spheres" demo
> won't react to key or mouse gestures when deployed. Could the gesture
> map set up by "set-gestures" be getting thrown out by the tree shaker?

The gestures were still there however the "superclass" word prop was
being stripped out and so the UI wasn't checking all of the gestures
that it should have checked. I have fixed this and pushed a deploy
descriptor for spheres too. Thanks for testing it out.

I also noticed that the UI layout in the deploy tool was all messed
up. I fixed this too.

Would you like to update Bunny at some point? It's in unmaintained
right now because it doesn't load, which is a shame. Delegation is
gone (so instead of construct-gadget, make a gadget subclass and use
new-gadget) and old accessors are going away soon. I could do it
eventually but it would be nice to have this taken off my plate.

Slava

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

headers

Joe Groff | 1 Sep 17:58

Re: <CFNumber> still references c-types at runtime in deployed image. Not sure why


On Sep 1, 2008, at 12:53 AM, Slava Pestov wrote:
> Would you like to update Bunny at some point? It's in unmaintained
> right now because it doesn't load, which is a shame. Delegation is
> gone (so instead of construct-gadget, make a gadget subclass and use
> new-gadget) and old accessors are going away soon. I could do it
> eventually but it would be nice to have this taken off my plate.

There was a stale call to "construct" in there which I updated to use  
boa. I also cleaned up some places in where "opengl.capabilities" was  
abusing >r/r>. "bunny" builds and runs fine for me now.

-Joe

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/