Immutable foundation objects
Hello. This is just a thought, but shouldn't for instance NSArray.alloc.init.frozen? return true, as it is immutable and cannot be changed? It is like a frozen version of NSMutableArray, isn't it? It's a bit confusing when asking an immutable Foundation object if it is frozen, and it says no... On the other hand, I suppose it's possible to create categories that add behavior that somehow modifies the object. Any thoughts on this? Thanks.
Hi Erik! NSArray, when instanciated, becomes the equivalent of a ruby array, see for yourself with macirb:
a = NSArray.alloc.init => [] a.class => Array
However, you are right, it might need to become frozen, because otherwise, this happens:
a << "MacRuby" 2010-02-15 11:57:08.766 macruby[98594:903] -[__NSArray0 addObject:]: unrecognized selector sent to instance 0x20022e820 uncaught Objective-C/C++ exception... 2010-02-15 11:57:08.795 macruby[98594:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSArray0 addObject:]: unrecognized selector sent to instance 0x20022e820'
And this is not really what we want :-) Laurent, what were your plans about that? Should we modify NSArray.m and use an NSMutableArray, or should we freeze NSArray instances? -- Thibault Martin-Lagardette On Feb 14, 2010, at 16:29, Erik Österlund wrote:
Hello.
This is just a thought, but shouldn't for instance NSArray.alloc.init.frozen? return true, as it is immutable and cannot be changed? It is like a frozen version of NSMutableArray, isn't it? It's a bit confusing when asking an immutable Foundation object if it is frozen, and it says no... On the other hand, I suppose it's possible to create categories that add behavior that somehow modifies the object.
Any thoughts on this?
Thanks. _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On Feb 15, 2010, at 3:18 AM, Thibault Martin-Lagardette wrote:
Hi Erik!
NSArray, when instanciated, becomes the equivalent of a ruby array, see for yourself with macirb:
a = NSArray.alloc.init => [] a.class => Array
However, you are right, it might need to become frozen, because otherwise, this happens:
a << "MacRuby" 2010-02-15 11:57:08.766 macruby[98594:903] -[__NSArray0 addObject:]: unrecognized selector sent to instance 0x20022e820 uncaught Objective-C/C++ exception... 2010-02-15 11:57:08.795 macruby[98594:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSArray0 addObject:]: unrecognized selector sent to instance 0x20022e820'
And this is not really what we want :-)
Laurent, what were your plans about that? Should we modify NSArray.m and use an NSMutableArray, or should we freeze NSArray instances?
This should behave as expected on 0.5, on 0.6 it is a work in progress :) Laurent
On Feb 15, 2010, at 3:18 AM, Thibault Martin-Lagardette wrote:
Hi Erik!
NSArray, when instanciated, becomes the equivalent of a ruby array, see for yourself with macirb:
a = NSArray.alloc.init => [] a.class => Array
However, you are right, it might need to become frozen, because otherwise, this happens:
a << "MacRuby" 2010-02-15 11:57:08.766 macruby[98594:903] -[__NSArray0 addObject:]: unrecognized selector sent to instance 0x20022e820 uncaught Objective-C/C++ exception... 2010-02-15 11:57:08.795 macruby[98594:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSArray0 addObject:]: unrecognized selector sent to instance 0x20022e820'
And this is not really what we want :-)
Laurent, what were your plans about that? Should we modify NSArray.m and use an NSMutableArray, or should we freeze NSArray instances?
This should behave as expected on 0.5, on 0.6 it is a work in progress :) Laurent
Hi -- I'm aware fork() is not implemented in MacRuby yet, and it may never be from what I read but I'd just like to introduce a use case i've come across recently that might have you reconsider? I am writing ruby bindings for the features exposed in the "sandbox" header, and you really need to fork a process if you don't want your parent process to inherit the restrictions the sandbox imposes .. I came across the problem with CoreFoundation not allowing you to fork() without immediately executing exec() , and I presume this is one of the reasons fork() in MacRuby might not be implemented but is there any workaround to see fork() being implemented? Just thought I'd add that to the table. Thanks, Rob
The recommendation is to use launchd to spawn processes via Service Management: http://developer.apple.com/mac/library/documentation/General/Reference/Servi... But I don't think anybody has wrapped it yet... -- Ernie P. On Feb 17, 2010, at 5:42 AM, robert gleeson wrote:
Hi --
I'm aware fork() is not implemented in MacRuby yet, and it may never be from what I read but I'd just like to introduce a use case i've come across recently that might have you reconsider?
I am writing ruby bindings for the features exposed in the "sandbox" header, and you really need to fork a process if you don't want your parent process to inherit the restrictions the sandbox imposes ..
I came across the problem with CoreFoundation not allowing you to fork() without immediately executing exec() , and I presume this is one of the reasons fork() in MacRuby might not be implemented but is there any workaround to see fork() being implemented?
Just thought I'd add that to the table.
Thanks, Rob _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Thanks Ernie -- I'm going to go through the documentation for the Service Management framework and see what I can come up with. I was hoping I wouldn't need to maintain two separate code bases for MacRuby and MRI but if i can launch processes without reverting to a hack it's always a good thing. Thanks, Rob On 17 Feb 2010, at 15:45, Ernest N. Prabhakar, Ph.D. wrote:
The recommendation is to use launchd to spawn processes via Service Management:
http://developer.apple.com/mac/library/documentation/General/Reference/Servi...
But I don't think anybody has wrapped it yet...
-- Ernie P.
On Feb 17, 2010, at 5:42 AM, robert gleeson wrote:
Hi --
I'm aware fork() is not implemented in MacRuby yet, and it may never be from what I read but I'd just like to introduce a use case i've come across recently that might have you reconsider?
I am writing ruby bindings for the features exposed in the "sandbox" header, and you really need to fork a process if you don't want your parent process to inherit the restrictions the sandbox imposes ..
I came across the problem with CoreFoundation not allowing you to fork() without immediately executing exec() , and I presume this is one of the reasons fork() in MacRuby might not be implemented but is there any workaround to see fork() being implemented?
Just thought I'd add that to the table.
Thanks, Rob _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi Robert, On Feb 17, 2010, at 8:18 AM, robert gleeson wrote:
Thanks Ernie --
I'm going to go through the documentation for the Service Management framework and see what I can come up with. I was hoping I wouldn't need to maintain two separate code bases for MacRuby and MRI but if i can launch processes without reverting to a hack it's always a good thing.
Let us know what you come up with. It is possible we may be able to (partially) emulate fork() using Service Management someday... -E
Thanks, Rob On 17 Feb 2010, at 15:45, Ernest N. Prabhakar, Ph.D. wrote:
The recommendation is to use launchd to spawn processes via Service Management:
http://developer.apple.com/mac/library/documentation/General/Reference/Servi...
But I don't think anybody has wrapped it yet...
-- Ernie P.
On Feb 17, 2010, at 5:42 AM, robert gleeson wrote:
Hi --
I'm aware fork() is not implemented in MacRuby yet, and it may never be from what I read but I'd just like to introduce a use case i've come across recently that might have you reconsider?
I am writing ruby bindings for the features exposed in the "sandbox" header, and you really need to fork a process if you don't want your parent process to inherit the restrictions the sandbox imposes ..
I came across the problem with CoreFoundation not allowing you to fork() without immediately executing exec() , and I presume this is one of the reasons fork() in MacRuby might not be implemented but is there any workaround to see fork() being implemented?
Just thought I'd add that to the table.
Thanks, Rob _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Ernie -- It's not immediately obvious to me how I would spawn a process that is a copy of the parent using Service Management and right now "framework('servicemanagement')" doesn't seem to expose the functions mentioned in the documentation for service management .. I've tried traversing through Object.constants for a namespace they might reside under but no joy. I'll try again tomorrow. Thanks, Rob On 17 Feb 2010, at 21:02, Ernest N. Prabhakar, Ph.D. wrote:
Hi Robert,
On Feb 17, 2010, at 8:18 AM, robert gleeson wrote:
Thanks Ernie --
I'm going to go through the documentation for the Service Management framework and see what I can come up with. I was hoping I wouldn't need to maintain two separate code bases for MacRuby and MRI but if i can launch processes without reverting to a hack it's always a good thing.
Let us know what you come up with. It is possible we may be able to (partially) emulate fork() using Service Management someday...
-E
Thanks, Rob On 17 Feb 2010, at 15:45, Ernest N. Prabhakar, Ph.D. wrote:
The recommendation is to use launchd to spawn processes via Service Management:
http://developer.apple.com/mac/library/documentation/General/Reference/Servi...
But I don't think anybody has wrapped it yet...
-- Ernie P.
On Feb 17, 2010, at 5:42 AM, robert gleeson wrote:
Hi --
I'm aware fork() is not implemented in MacRuby yet, and it may never be from what I read but I'd just like to introduce a use case i've come across recently that might have you reconsider?
I am writing ruby bindings for the features exposed in the "sandbox" header, and you really need to fork a process if you don't want your parent process to inherit the restrictions the sandbox imposes ..
I came across the problem with CoreFoundation not allowing you to fork() without immediately executing exec() , and I presume this is one of the reasons fork() in MacRuby might not be implemented but is there any workaround to see fork() being implemented?
Just thought I'd add that to the table.
Thanks, Rob _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi Rob, On Feb 17, 2010, at 4:45 PM, robert gleeson wrote:
Ernie --
It's not immediately obvious to me how I would spawn a process that is a copy of the parent using Service Management and right now "framework('servicemanagement')" doesn't seem to expose the functions mentioned in the documentation for service management .. I've tried traversing through Object.constants for a namespace they might reside under but no joy.
I'm sorry, I didn't realize you wanted a true "fork"; SM just launches new processes 'ab initio'. So, I'm afraid you're probably out of luck. For the record, what exactly is the use case where you want/need to inherit the parent environment in the sub-process? -- Ernie P.
I'll try again tomorrow.
Thanks, Rob
On 17 Feb 2010, at 21:02, Ernest N. Prabhakar, Ph.D. wrote:
Hi Robert,
On Feb 17, 2010, at 8:18 AM, robert gleeson wrote:
Thanks Ernie --
I'm going to go through the documentation for the Service Management framework and see what I can come up with. I was hoping I wouldn't need to maintain two separate code bases for MacRuby and MRI but if i can launch processes without reverting to a hack it's always a good thing.
Let us know what you come up with. It is possible we may be able to (partially) emulate fork() using Service Management someday...
-E
Thanks, Rob On 17 Feb 2010, at 15:45, Ernest N. Prabhakar, Ph.D. wrote:
The recommendation is to use launchd to spawn processes via Service Management:
http://developer.apple.com/mac/library/documentation/General/Reference/Servi...
But I don't think anybody has wrapped it yet...
-- Ernie P.
On Feb 17, 2010, at 5:42 AM, robert gleeson wrote:
Hi --
I'm aware fork() is not implemented in MacRuby yet, and it may never be from what I read but I'd just like to introduce a use case i've come across recently that might have you reconsider?
I am writing ruby bindings for the features exposed in the "sandbox" header, and you really need to fork a process if you don't want your parent process to inherit the restrictions the sandbox imposes ..
I came across the problem with CoreFoundation not allowing you to fork() without immediately executing exec() , and I presume this is one of the reasons fork() in MacRuby might not be implemented but is there any workaround to see fork() being implemented?
Just thought I'd add that to the table.
Thanks, Rob _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Ernie Thanks for the reply and no problem .. I don't truly need to fork because all I want is a process that i can initiate a sandbox under using sandbox_init(). The "problem" is, I feel being able to spawn a child process without a separate codebase for initiating the sandbox is a much nicer solution, and then comes the problem of communicating the options for the sandbox between two processes that don't share any state. The parent also has the PID of the child, which makes a #terminate method very easy to implement. I've no idea about Service Management so maybe this information could be shared in some way, it just feels easier and cleaner to do so using fork() so the library would be one entity. If it helps give an idea, i've currently implemented this in MRI using fork(): http://github.com/robgleeson/Dia/tree/experimental Thanks, Rob On 18 Feb 2010, at 00:51, Ernest N. Prabhakar, Ph.D. wrote:
Hi Rob,
On Feb 17, 2010, at 4:45 PM, robert gleeson wrote:
Ernie --
It's not immediately obvious to me how I would spawn a process that is a copy of the parent using Service Management and right now "framework('servicemanagement')" doesn't seem to expose the functions mentioned in the documentation for service management .. I've tried traversing through Object.constants for a namespace they might reside under but no joy.
I'm sorry, I didn't realize you wanted a true "fork"; SM just launches new processes 'ab initio'. So, I'm afraid you're probably out of luck.
For the record, what exactly is the use case where you want/need to inherit the parent environment in the sub-process?
-- Ernie P.
I'll try again tomorrow.
Thanks, Rob
On 17 Feb 2010, at 21:02, Ernest N. Prabhakar, Ph.D. wrote:
Hi Robert,
On Feb 17, 2010, at 8:18 AM, robert gleeson wrote:
Thanks Ernie --
I'm going to go through the documentation for the Service Management framework and see what I can come up with. I was hoping I wouldn't need to maintain two separate code bases for MacRuby and MRI but if i can launch processes without reverting to a hack it's always a good thing.
Let us know what you come up with. It is possible we may be able to (partially) emulate fork() using Service Management someday...
-E
Thanks, Rob On 17 Feb 2010, at 15:45, Ernest N. Prabhakar, Ph.D. wrote:
The recommendation is to use launchd to spawn processes via Service Management:
http://developer.apple.com/mac/library/documentation/General/Reference/Servi...
But I don't think anybody has wrapped it yet...
-- Ernie P.
On Feb 17, 2010, at 5:42 AM, robert gleeson wrote:
Hi --
I'm aware fork() is not implemented in MacRuby yet, and it may never be from what I read but I'd just like to introduce a use case i've come across recently that might have you reconsider?
I am writing ruby bindings for the features exposed in the "sandbox" header, and you really need to fork a process if you don't want your parent process to inherit the restrictions the sandbox imposes ..
I came across the problem with CoreFoundation not allowing you to fork() without immediately executing exec() , and I presume this is one of the reasons fork() in MacRuby might not be implemented but is there any workaround to see fork() being implemented?
Just thought I'd add that to the table.
Thanks, Rob _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi Rob, On Feb 17, 2010, at 5:02 PM, robert gleeson wrote:
Ernie
Thanks for the reply and no problem .. I don't truly need to fork because all I want is a process that i can initiate a sandbox under using sandbox_init().
The "problem" is, I feel being able to spawn a child process without a separate codebase for initiating the sandbox is a much nicer solution, and then comes the problem of communicating the options for the sandbox between two processes that don't share any state. The parent also has the PID of the child, which makes a #terminate method very easy to implement. I've no idea about Service Management so maybe this information could be shared in some way, it just feels easier and cleaner to do so using fork() so the library would be one entity.
If it helps give an idea, i've currently implemented this in MRI using fork(): http://github.com/robgleeson/Dia/tree/experimental
Interesting. For what its worth SM and launchd intend to make it easy to factor your application into processes with different security levels. Alas, it isn't yet as trivial as one might wish. I've wondered whether it might be possible to mock something up using Distributed Ruby and SM, but neither is very mature on MacRuby at the moment. -- Ernie P.
Thanks, Rob
On 18 Feb 2010, at 00:51, Ernest N. Prabhakar, Ph.D. wrote:
Hi Rob,
On Feb 17, 2010, at 4:45 PM, robert gleeson wrote:
Ernie --
It's not immediately obvious to me how I would spawn a process that is a copy of the parent using Service Management and right now "framework('servicemanagement')" doesn't seem to expose the functions mentioned in the documentation for service management .. I've tried traversing through Object.constants for a namespace they might reside under but no joy.
I'm sorry, I didn't realize you wanted a true "fork"; SM just launches new processes 'ab initio'. So, I'm afraid you're probably out of luck.
For the record, what exactly is the use case where you want/need to inherit the parent environment in the sub-process?
-- Ernie P.
I'll try again tomorrow.
Thanks, Rob
On 17 Feb 2010, at 21:02, Ernest N. Prabhakar, Ph.D. wrote:
Hi Robert,
On Feb 17, 2010, at 8:18 AM, robert gleeson wrote:
Thanks Ernie --
I'm going to go through the documentation for the Service Management framework and see what I can come up with. I was hoping I wouldn't need to maintain two separate code bases for MacRuby and MRI but if i can launch processes without reverting to a hack it's always a good thing.
Let us know what you come up with. It is possible we may be able to (partially) emulate fork() using Service Management someday...
-E
Thanks, Rob On 17 Feb 2010, at 15:45, Ernest N. Prabhakar, Ph.D. wrote:
The recommendation is to use launchd to spawn processes via Service Management:
http://developer.apple.com/mac/library/documentation/General/Reference/Servi...
But I don't think anybody has wrapped it yet...
-- Ernie P.
On Feb 17, 2010, at 5:42 AM, robert gleeson wrote:
> Hi -- > > I'm aware fork() is not implemented in MacRuby yet, and it may never be from what I read but I'd just like to introduce a use case i've come across recently that might have you reconsider? > > I am writing ruby bindings for the features exposed in the "sandbox" header, and you really need to fork a process if you don't want your parent process to inherit the restrictions the sandbox imposes .. > > I came across the problem with CoreFoundation not allowing you to fork() without immediately executing exec() , and I presume this is one of the reasons fork() in MacRuby might not be implemented but is there any workaround to see fork() being implemented? > > Just thought I'd add that to the table. > > Thanks, > Rob > _______________________________________________ > MacRuby-devel mailing list > MacRuby-devel@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (5)
-
Erik Österlund
-
Ernest N. Prabhakar, Ph.D.
-
Laurent Sansonetti
-
robert gleeson
-
Thibault Martin-Lagardette