Building OSProcessPlugin on macs
Locked
Building OSProcessPlugin on macs
 
|
I trying to make a working OSProcessPlugin for mac vms. Okay, i loaded the VMConstruction-Plugins-OSProcessPlugin.oscog-eem.30 and then building VM with: StackMacOSConfig new addExternalPlugins: #( FT2Plugin ); addInternalPlugins: #( UnixOSProcessPlugin ); generateSources; generate. (this is new api which i recently added to make it easier to generate VM with custom set of plugins) It builds fine as internal plugin (fails as external one of course, because no access to these variables: Linking C shared library /Users/sig/projects/cog/sig-cog/results/StackVM.app/Contents/Resources/libUnixOSProcessPlugin.dylib Undefined symbols: "_envVec", referenced from: _envVec$non_lazy_ptr in UnixOSProcessPlugin.c.o (maybe you meant: _envVec$non_lazy_ptr) "_primitiveFail", referenced from: _primitiveIsAtEndOfFile in UnixOSProcessPlugin.c.o "_argCnt", referenced from: _argCnt$non_lazy_ptr in UnixOSProcessPlugin.c.o (maybe you meant: _argCnt$non_lazy_ptr) "_argVec", referenced from: _argVec$non_lazy_ptr in UnixOSProcessPlugin.c.o (maybe you meant: _argVec$non_lazy_ptr) "_sqFileStdioHandlesInto", referenced from: _getStdHandle in UnixOSProcessPlugin.c.o ld: symbol(s) not found Remember we're discussed this, and i think we should add an API function for this, instead of relying on linker to bind those symbols at run time. Because this is too brittle and vague for external plugin. Okay, at least internal one builds, but then when i run tests.. a dozen of them failing. UnixProcessTestCase: 18 run, 3 passes, 0 expected failures, 14 failures, 1 errors, 0 unexpected passes UnixProcessFileLockTestCase 23 run, 23 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes UnixProcessAccessorTestCase 46 run, 46 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes OSPipeTestCase 11 run, 11 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes UnixProcessUnixFileLockingTestCase 40 run, 12 passes, 0 expected failures, 28 failures, 0 errors, 0 unexpected passes UnixProcessWin32FileLockingTestCase 40 run, 12 passes, 0 expected failures, 28 failures, 0 errors, 0 unexpected passes Maybe i'm using wrong package for image-side code? I loaded OSProcess package, but i see there are separate OSProcess-Base , OSProcess-Mac, OSProcess-Tests etc are they identical (since i see that David updating both), or it is better to use splitted versions? @Esteban, i see that you also making UnixOSProcessPlugin, but i wonder what is this: configureUnixOSProcessPlugin: maker super configureHostWindowPlugin: maker. maker includeDirectories: '${platformsDir}/Cross/plugins/SocketPlugin'. why it uses rather unrelated configureHostWindowPlugin: there? Because mine (which for Carbon builds) are following: configureUnixOSProcessPlugin: maker "extra rules for UnixOSProcessPlugin" maker includeDirectories: '${crossDir}/plugins/FilePlugin'. I am missing something? Please let me know. -- Best regards, Igor Stasenko AKA sig. |
Re: Building OSProcessPlugin on macs
|
|
Okay, there's one more problem, which i was unable to detect, because i didn't closed the image :) VM is crashing at shutdown stage. The offenred is: primitiveMakePipeWithSessionIdentifier. It doesn't crashing if you using image without OSProcess code loaded, only if image has it, you have such problems. Here what debugger producing: Program received signal: “EXC_BAD_ACCESS”. warning: Attempting to create USE_BLOCK_IN_FRAME variable with block that isn't in the frame. warning: Attempting to create USE_BLOCK_IN_FRAME variable with block that isn't in the frame. warning: Attempting to create USE_BLOCK_IN_FRAME variable with block that isn't in the frame. warning: Attempting to create USE_BLOCK_IN_FRAME variable with block that isn't in the frame. warning: Attempting to create USE_BLOCK_IN_FRAME variable with block that isn't in the frame. warning: Attempting to create USE_BLOCK_IN_FRAME variable with block that isn't in the frame. warning: Attempting to create USE_BLOCK_IN_FRAME variable with block that isn't in the frame. warning: Attempting to create USE_BLOCK_IN_FRAME variable with block that isn't in the frame. Unable to disassemble primitiveMakePipeWithSessionIdentifier. (i will build a debug version of VM tomorrow, to see if debugger can be more elaborate) but it is clear that its crashing inside this primitive. -- Best regards, Igor Stasenko AKA sig. |
Re: Building OSProcessPlugin on macs
|
|
In reply to this post by Igor Stasenko
On Wed, Jul 06, 2011 at 05:53:44PM +0200, Igor Stasenko wrote: > > I trying to make a working OSProcessPlugin for mac vms. > > Okay, i loaded the > VMConstruction-Plugins-OSProcessPlugin.oscog-eem.30 > > and then building VM with: > > StackMacOSConfig new > addExternalPlugins: #( FT2Plugin ); > addInternalPlugins: #( UnixOSProcessPlugin ); > generateSources; generate. > > (this is new api which i recently added to make it easier to generate > VM with custom set of plugins) > > It builds fine as internal plugin (fails as external one of course, > because no access to these variables: > > Linking C shared library > /Users/sig/projects/cog/sig-cog/results/StackVM.app/Contents/Resources/libUnixOSProcessPlugin.dylib > Undefined symbols: > "_envVec", referenced from: > _envVec$non_lazy_ptr in UnixOSProcessPlugin.c.o > (maybe you meant: _envVec$non_lazy_ptr) > "_primitiveFail", referenced from: > _primitiveIsAtEndOfFile in UnixOSProcessPlugin.c.o > "_argCnt", referenced from: > _argCnt$non_lazy_ptr in UnixOSProcessPlugin.c.o > (maybe you meant: _argCnt$non_lazy_ptr) > "_argVec", referenced from: > _argVec$non_lazy_ptr in UnixOSProcessPlugin.c.o > (maybe you meant: _argVec$non_lazy_ptr) > "_sqFileStdioHandlesInto", referenced from: > _getStdHandle in UnixOSProcessPlugin.c.o > ld: symbol(s) not found > > Remember we're discussed this, and i think we should add an API > function for this, instead of relying on linker to bind those symbols > at run time. > Because this is too brittle and vague for external plugin. I think this is just controlled by a compiler option on Mac. I don't have a link to the discussion, but perhaps Esteban will remember the details. > > Okay, at least internal one builds, but then when i run tests.. a > dozen of them failing. > > UnixProcessTestCase: > 18 run, 3 passes, 0 expected failures, 14 failures, 1 errors, 0 > unexpected passes > > UnixProcessFileLockTestCase > 23 run, 23 passes, 0 expected failures, 0 failures, 0 errors, 0 > unexpected passes > > UnixProcessAccessorTestCase > 46 run, 46 passes, 0 expected failures, 0 failures, 0 errors, 0 > unexpected passes > > OSPipeTestCase > 11 run, 11 passes, 0 expected failures, 0 failures, 0 errors, 0 > unexpected passes > > UnixProcessUnixFileLockingTestCase > 40 run, 12 passes, 0 expected failures, 28 failures, 0 errors, 0 > unexpected passes > > UnixProcessWin32FileLockingTestCase > 40 run, 12 passes, 0 expected failures, 28 failures, 0 errors, 0 > unexpected passes Many of the tests rely on #forkSqueak, which in turn relies on controlling the display with XDisplayControlPlugin, which is not available on Mac. > > Maybe i'm using wrong package for image-side code? > I loaded OSProcess package, > but i see there are separate OSProcess-Base , OSProcess-Mac, OSProcess-Tests etc > > are they identical (since i see that David updating both), or it is > better to use splitted versions? > Using the OSProcess package is fine. I split it apart into sub-packages because "modularity is good so more modularity must be better". Bad idea, it did not help anything and now I have to maintain *all* those sub-packages in addition to the OSProcess package. In any case, loading the most recent OSProcess is the right thing to do. Speaking of modularity, I long ago split OSProcessPlugin into OSProcessPlugin + AioPlugin + XDisplayControlPlugin. This actually *was* a good idea. But if I could ask a favor, could you please try compiling AioPlugin for a Mac VM and see if it works? I expect that it probably will work because the Mac VM uses the aio code from the Unix VM, but I don't think that it has ever been tried. The unit tests for OSProcess should confirm this (see AioEventHandlerTestCase). Thanks! Dave > @Esteban, i see that you also making UnixOSProcessPlugin, but i wonder > what is this: > > configureUnixOSProcessPlugin: maker > super configureHostWindowPlugin: maker. > maker includeDirectories: '${platformsDir}/Cross/plugins/SocketPlugin'. > > > why it uses rather unrelated configureHostWindowPlugin: there? > > Because mine (which for Carbon builds) are following: > > configureUnixOSProcessPlugin: maker > "extra rules for UnixOSProcessPlugin" > > maker includeDirectories: '${crossDir}/plugins/FilePlugin'. > > I am missing something? Please let me know. > > > -- > Best regards, > Igor Stasenko AKA sig. |
|
|
I"ve compiled the aioPlugin in the past. Some of the tests will fail because you cann't fork the VM into two processes because the UI is tied to the main pthread for the App, so a fork leads to insanity & a core dump. Otherwise since OS-X is a Unix machine it should run all the other test cases. On Wed, Jul 6, 2011 at 8:43 PM, David T. Lewis <[hidden email]> wrote: > > On Wed, Jul 06, 2011 at 05:53:44PM +0200, Igor Stasenko wrote: >> >> I trying to make a working OSProcessPlugin for mac vms. >> >> Okay, i loaded the >> VMConstruction-Plugins-OSProcessPlugin.oscog-eem.30 >> >> and then building VM with: >> >> StackMacOSConfig new >> addExternalPlugins: #( FT2Plugin ); >> addInternalPlugins: #( UnixOSProcessPlugin ); >> generateSources; generate. >> >> (this is new api which i recently added to make it easier to generate >> VM with custom set of plugins) >> >> It builds fine as internal plugin (fails as external one of course, >> because no access to these variables: >> >> Linking C shared library >> /Users/sig/projects/cog/sig-cog/results/StackVM.app/Contents/Resources/libUnixOSProcessPlugin.dylib >> Undefined symbols: >> "_envVec", referenced from: >> _envVec$non_lazy_ptr in UnixOSProcessPlugin.c.o >> (maybe you meant: _envVec$non_lazy_ptr) >> "_primitiveFail", referenced from: >> _primitiveIsAtEndOfFile in UnixOSProcessPlugin.c.o >> "_argCnt", referenced from: >> _argCnt$non_lazy_ptr in UnixOSProcessPlugin.c.o >> (maybe you meant: _argCnt$non_lazy_ptr) >> "_argVec", referenced from: >> _argVec$non_lazy_ptr in UnixOSProcessPlugin.c.o >> (maybe you meant: _argVec$non_lazy_ptr) >> "_sqFileStdioHandlesInto", referenced from: >> _getStdHandle in UnixOSProcessPlugin.c.o >> ld: symbol(s) not found >> >> Remember we're discussed this, and i think we should add an API >> function for this, instead of relying on linker to bind those symbols >> at run time. >> Because this is too brittle and vague for external plugin. > > I think this is just controlled by a compiler option on Mac. I don't > have a link to the discussion, but perhaps Esteban will remember the > details. > >> >> Okay, at least internal one builds, but then when i run tests.. a >> dozen of them failing. >> >> UnixProcessTestCase: >> 18 run, 3 passes, 0 expected failures, 14 failures, 1 errors, 0 >> unexpected passes >> >> UnixProcessFileLockTestCase >> 23 run, 23 passes, 0 expected failures, 0 failures, 0 errors, 0 >> unexpected passes >> >> UnixProcessAccessorTestCase >> 46 run, 46 passes, 0 expected failures, 0 failures, 0 errors, 0 >> unexpected passes >> >> OSPipeTestCase >> 11 run, 11 passes, 0 expected failures, 0 failures, 0 errors, 0 >> unexpected passes >> >> UnixProcessUnixFileLockingTestCase >> 40 run, 12 passes, 0 expected failures, 28 failures, 0 errors, 0 >> unexpected passes >> >> UnixProcessWin32FileLockingTestCase >> 40 run, 12 passes, 0 expected failures, 28 failures, 0 errors, 0 >> unexpected passes > > Many of the tests rely on #forkSqueak, which in turn relies on > controlling the display with XDisplayControlPlugin, which is not > available on Mac. > >> >> Maybe i'm using wrong package for image-side code? >> I loaded OSProcess package, >> but i see there are separate OSProcess-Base , OSProcess-Mac, OSProcess-Tests etc >> >> are they identical (since i see that David updating both), or it is >> better to use splitted versions? >> > > Using the OSProcess package is fine. I split it apart into sub-packages > because "modularity is good so more modularity must be better". Bad > idea, it did not help anything and now I have to maintain *all* those > sub-packages in addition to the OSProcess package. In any case, loading > the most recent OSProcess is the right thing to do. > > Speaking of modularity, I long ago split OSProcessPlugin into > OSProcessPlugin + AioPlugin + XDisplayControlPlugin. This actually > *was* a good idea. But if I could ask a favor, could you please > try compiling AioPlugin for a Mac VM and see if it works? I expect > that it probably will work because the Mac VM uses the aio code > from the Unix VM, but I don't think that it has ever been tried. > The unit tests for OSProcess should confirm this (see AioEventHandlerTestCase). > > Thanks! > Dave > >> @Esteban, i see that you also making UnixOSProcessPlugin, but i wonder >> what is this: >> >> configureUnixOSProcessPlugin: maker >> super configureHostWindowPlugin: maker. >> maker includeDirectories: '${platformsDir}/Cross/plugins/SocketPlugin'. >> >> >> why it uses rather unrelated configureHostWindowPlugin: there? >> >> Because mine (which for Carbon builds) are following: >> >> configureUnixOSProcessPlugin: maker >> "extra rules for UnixOSProcessPlugin" >> >> maker includeDirectories: '${crossDir}/plugins/FilePlugin'. >> >> I am missing something? Please let me know. >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > -- =========================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
Re: Building OSProcessPlugin on macs
|
|
Aha.. so failing tests are because fork is unavailable. David, could you change the relevant tests to not fail but rather pass or 'expected fail' when running on macs? because i'd like to know how well it is, and to know that i wanna see clear picture what are problems if any. And, any hints why primitiveMakePipeWithSessionIdentifier. might crash the VM? On 7 July 2011 03:52, John McIntosh <[hidden email]> wrote: > > I"ve compiled the aioPlugin in the past. > > Some of the tests will fail because you cann't fork the VM into two > processes because the UI is tied to the main pthread for the App, so a > fork leads to insanity & a core dump. > Otherwise since OS-X is a Unix machine it should run all the other test cases. > -- Best regards, Igor Stasenko AKA sig. |
Re: Building OSProcessPlugin on macs
|
|
With a new version of plugin submitted by Eliot it no longer crashing :) On 7 July 2011 03:18, Igor Stasenko <[hidden email]> wrote: > Aha.. so failing tests are because fork is unavailable. > David, could you change the relevant tests to not fail but rather pass > or 'expected fail' > when running on macs? > because i'd like to know how well it is, and to know that i wanna see > clear picture what are problems if any. > > And, any hints why primitiveMakePipeWithSessionIdentifier. might crash the VM? > > On 7 July 2011 03:52, John McIntosh <[hidden email]> wrote: >> >> I"ve compiled the aioPlugin in the past. >> >> Some of the tests will fail because you cann't fork the VM into two >> processes because the UI is tied to the main pthread for the App, so a >> fork leads to insanity & a core dump. >> Otherwise since OS-X is a Unix machine it should run all the other test cases. >> > > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. |
Re: Building OSProcessPlugin on macs
|
|
On Wed, Jul 6, 2011 at 6:31 PM, Igor Stasenko <[hidden email]> wrote:
Slang is occasionally super-tricky. If you write self atexit: #sendSignalToPids
it generates atexit("sendSignalToPids") which will crash. You must write self atexit: #sendSignalToPids asSymbol
to get it to generate atexit(sendSignalToPids) (where sendSignalToPids is some function to be called at exit). If course we should change this but there's backwards-compatibility for plugin to consider. Does anyone depend on the old behavior? I've been bitten more than a few times by this. Sigh...
-- best, Eliot |
Re: Building OSProcessPlugin on macs
|
|
I think symbols should not be translated to strings by generator. This will allow to avoid many many mistakes. If i remember , in Hydra i also added something to translate things like #fnName asCIdentifier because i also wanted to use symbolic names. On 7 July 2011 03:38, Eliot Miranda <[hidden email]> wrote: > > > > On Wed, Jul 6, 2011 at 6:31 PM, Igor Stasenko <[hidden email]> wrote: >> >> With a new version of plugin submitted by Eliot it no longer crashing :) > > Slang is occasionally super-tricky. If you write > self atexit: #sendSignalToPids > it generates > atexit("sendSignalToPids") > which will crash. You must write > self atexit: #sendSignalToPids asSymbol > to get it to generate > atexit(sendSignalToPids) > (where sendSignalToPids is some function to be called at exit). > If course we should change this but there's backwards-compatibility for plugin to consider. Does anyone depend on the old behavior? I've been bitten more than a few times by this. Sigh... >> >> On 7 July 2011 03:18, Igor Stasenko <[hidden email]> wrote: >> > Aha.. so failing tests are because fork is unavailable. >> > David, could you change the relevant tests to not fail but rather pass >> > or 'expected fail' >> > when running on macs? >> > because i'd like to know how well it is, and to know that i wanna see >> > clear picture what are problems if any. >> > >> > And, any hints why primitiveMakePipeWithSessionIdentifier. might crash the VM? >> > >> > On 7 July 2011 03:52, John McIntosh <[hidden email]> wrote: >> >> >> >> I"ve compiled the aioPlugin in the past. >> >> >> >> Some of the tests will fail because you cann't fork the VM into two >> >> processes because the UI is tied to the main pthread for the App, so a >> >> fork leads to insanity & a core dump. >> >> Otherwise since OS-X is a Unix machine it should run all the other test cases. >> >> >> > >> > >> > >> > >> > -- >> > Best regards, >> > Igor Stasenko AKA sig. >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > > > -- > best, > Eliot > > -- Best regards, Igor Stasenko AKA sig. |
Re: Building OSProcessPlugin on macs
|
|
@All I modified following jobs on Hudson to include OSProcessPlugin as internal one. https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Unix/ https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog-Mac-Carbon/ https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Stack%20VM%20Unix/ https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/StackVM-Mac-Carbon/ (and of course there are already fresh-hot VMs with this plugin inside). Today i will see what can be done on windows. And will try aio plugin on macs. I'd like to ask you to pick one of those VMs and check failing tests to see which one of them are real failures and which ones not. Because i never used this plugin seriously, and i don't know if it works at all :) -- Best regards, Igor Stasenko AKA sig. |
Re: Building OSProcessPlugin on macs
|
|
In reply to this post by Eliot Miranda-2
On Wed, Jul 06, 2011 at 06:38:10PM -0700, Eliot Miranda wrote: > > On Wed, Jul 6, 2011 at 6:31 PM, Igor Stasenko <[hidden email]> wrote: > > > > > With a new version of plugin submitted by Eliot it no longer crashing :) > > > > Slang is occasionally super-tricky. If you write > > self atexit: #sendSignalToPids > > it generates > > atexit("sendSignalToPids") > > which will crash. You must write > > self atexit: #sendSignalToPids asSymbol > > to get it to generate > > atexit(sendSignalToPids) > > (where sendSignalToPids is some function to be called at exit). > > If course we should change this but there's backwards-compatibility for > plugin to consider. Does anyone depend on the old behavior? I've been > bitten more than a few times by this. Sigh... Symbols and strings are used more or less interchangably in C translation (aka "slang") and in pragmas. So I think that there is a general expectation that either a symbol or a string would translate to C as a string. In the case of #sendSignalToPids, this is actually a function pointer that is being used in a rather specialized context. So even though the translation of 'self atexit: #sendSignalToPids' produces a surprising result in this case, I would still say that is reasonable to expect Smalltalk symbols and strings to both translate into C strings, and it would not be reasonable to expect a simple C translator to do enough type checking to figure out that in this particular case the '#sendSignalToPids' should be treated as a function pointer rather than as a string. The original method in UnixOSProcessPlugin is written as follows in order to avoid this issue: self cCode: 'atexit(sendSignalToPids)'. I also note that the purpose of SlangBrowser is to make it easy to review code like this while it is being written, so I guess that I should get off my butt and get this working in the oscog branch one of these days :-/ Dave |
Re: Building OSProcessPlugin on macs
|
|
On 7 July 2011 05:28, David T. Lewis <[hidden email]> wrote: > > On Wed, Jul 06, 2011 at 06:38:10PM -0700, Eliot Miranda wrote: >> >> On Wed, Jul 6, 2011 at 6:31 PM, Igor Stasenko <[hidden email]> wrote: >> >> > >> > With a new version of plugin submitted by Eliot it no longer crashing :) >> > >> >> Slang is occasionally super-tricky. If you write >> >> self atexit: #sendSignalToPids >> >> it generates >> >> atexit("sendSignalToPids") >> >> which will crash. You must write >> >> self atexit: #sendSignalToPids asSymbol >> >> to get it to generate >> >> atexit(sendSignalToPids) >> >> (where sendSignalToPids is some function to be called at exit). >> >> If course we should change this but there's backwards-compatibility for >> plugin to consider. Does anyone depend on the old behavior? I've been >> bitten more than a few times by this. Sigh... > > Symbols and strings are used more or less interchangably in C translation > (aka "slang") and in pragmas. So I think that there is a general expectation > that either a symbol or a string would translate to C as a string. In > the case of #sendSignalToPids, this is actually a function pointer that > is being used in a rather specialized context. So even though the > translation of 'self atexit: #sendSignalToPids' produces a surprising > result in this case, I would still say that is reasonable to expect > Smalltalk symbols and strings to both translate into C strings, and > it would not be reasonable to expect a simple C translator to do > enough type checking to figure out that in this particular case the > '#sendSignalToPids' should be treated as a function pointer rather > than as a string. > I concur not. As to me a least surprising behaviour for code generator would be to covert symbols to identifiers with same name, instead of literal strings. > The original method in UnixOSProcessPlugin is written as follows in > order to avoid this issue: > > self cCode: 'atexit(sendSignalToPids)'. > the problem with above code that it doesn't tells code generator to keep sendSignalToPids method around, instead of pruning it since nobody using it. That's why in hydra i added this special asCIdentifier to not only convert symbol to identifier (instead of quoted C string) but also make sure that if given symbol matching the method name , then make sure that this method won't be pruned. And of course , when browsing the code i can see senders of it, while if i forced to use cCode: 'yaddayadda', it will hide the usage from our eyes. So, one way or another, but the less cCode: we have, the better. > I also note that the purpose of SlangBrowser is to make it easy to > review code like this while it is being written, so I guess that I > should get off my butt and get this working in the oscog branch one > of these days :-/ > > Dave > > -- Best regards, Igor Stasenko AKA sig. |
Re: Building OSProcessPlugin on macs
|
|
On Thu, Jul 07, 2011 at 05:36:51AM +0200, Igor Stasenko wrote: > > On 7 July 2011 05:28, David T. Lewis <[hidden email]> wrote: > > > > On Wed, Jul 06, 2011 at 06:38:10PM -0700, Eliot Miranda wrote: > >> > >> On Wed, Jul 6, 2011 at 6:31 PM, Igor Stasenko <[hidden email]> wrote: > >> > >> > > >> > With a new version of plugin submitted by Eliot it no longer crashing :) > >> > > >> > >> Slang is occasionally super-tricky. ??If you write > >> > >> ?? ?? self atexit: #sendSignalToPids > >> > >> it generates > >> > >> ?? ?? atexit("sendSignalToPids") > >> > >> which will crash. ??You must write > >> > >> ?? ?? self atexit: #sendSignalToPids asSymbol > >> > >> to get it to generate > >> > >> ?? ?? atexit(sendSignalToPids) > >> > >> (where sendSignalToPids is some function to be called at exit). > >> > >> If course we should change this but there's backwards-compatibility for > >> plugin to consider. ??Does anyone depend on the old behavior? ??I've been > >> bitten more than a few times by this. ??Sigh... > > > > Symbols and strings are used more or less interchangably in C translation > > (aka "slang") and in pragmas. So I think that there is a general expectation > > that either a symbol or a string would translate to C as a string. In > > the case of #sendSignalToPids, this is actually a function pointer that > > is being used in a rather specialized context. So even though the > > translation of 'self atexit: #sendSignalToPids' produces a surprising > > result in this case, I would still say that is reasonable to expect > > Smalltalk symbols and strings to both translate into C strings, and > > it would not be reasonable to expect a simple C translator to do > > enough type checking to figure out that in this particular case the > > '#sendSignalToPids' should be treated as a function pointer rather > > than as a string. > > > > I concur not. As to me a least surprising behaviour for code generator > would be to covert symbols to > identifiers with same name, instead of literal strings. > > > > The original method in UnixOSProcessPlugin is written as follows in > > order to avoid this issue: > > > > ?? ?? ?? ??self cCode: 'atexit(sendSignalToPids)'. > > > > the problem with above code that it doesn't tells code generator to > keep sendSignalToPids method around, > instead of pruning it since nobody using it. > That's why in hydra i added this special asCIdentifier to not only > convert symbol to identifier (instead of quoted C string) > but also make sure that if given symbol matching the method name , > then make sure that this method won't be pruned. I don't understand why this was a problem in hydra. The method is referenced from #initialiseModule, and is not pruned by the code generator for that reason. > > And of course , when browsing the code i can see senders of it, while > if i forced to use cCode: 'yaddayadda', > it will hide the usage from our eyes. > > So, one way or another, but the less cCode: we have, the better. As a general rule, yes. In this specific case, no. I wrote the method that way for a reason, and it is correct as written. It is correct because the code snippet has no meaningful equivalent in interpreter simulation, it involves non-trivial C variable type declarations, and it avoids hiding the intent of the code behind mysterious slang translations. You can understand how it works by reading the method in Smalltalk, and there is no possibility of error due to "unexpected" C translation. I am not saying that writing "self atexit: #sendSignalToPids asSymbol" is wrong, but you would be hard pressed to convince me that it is easier to read and understand. Note that the "self atexit: ..." change exists only in the oscog branch. I don't know the motivation for that change, so maybe I'm missing something. Dave > > > I also note that the purpose of SlangBrowser is to make it easy to > > review code like this while it is being written, so I guess that I > > should get off my butt and get this working in the oscog branch one > > of these days :-/ > > > > Dave > > |
Re: Building OSProcessPlugin on macs
|
|
On 7 July 2011 14:22, David T. Lewis <[hidden email]> wrote: > > On Thu, Jul 07, 2011 at 05:36:51AM +0200, Igor Stasenko wrote: >> >> On 7 July 2011 05:28, David T. Lewis <[hidden email]> wrote: >> > >> > On Wed, Jul 06, 2011 at 06:38:10PM -0700, Eliot Miranda wrote: >> >> >> >> On Wed, Jul 6, 2011 at 6:31 PM, Igor Stasenko <[hidden email]> wrote: >> >> >> >> > >> >> > With a new version of plugin submitted by Eliot it no longer crashing :) >> >> > >> >> >> >> Slang is occasionally super-tricky. ??If you write >> >> >> >> ?? ?? self atexit: #sendSignalToPids >> >> >> >> it generates >> >> >> >> ?? ?? atexit("sendSignalToPids") >> >> >> >> which will crash. ??You must write >> >> >> >> ?? ?? self atexit: #sendSignalToPids asSymbol >> >> >> >> to get it to generate >> >> >> >> ?? ?? atexit(sendSignalToPids) >> >> >> >> (where sendSignalToPids is some function to be called at exit). >> >> >> >> If course we should change this but there's backwards-compatibility for >> >> plugin to consider. ??Does anyone depend on the old behavior? ??I've been >> >> bitten more than a few times by this. ??Sigh... >> > >> > Symbols and strings are used more or less interchangably in C translation >> > (aka "slang") and in pragmas. So I think that there is a general expectation >> > that either a symbol or a string would translate to C as a string. In >> > the case of #sendSignalToPids, this is actually a function pointer that >> > is being used in a rather specialized context. So even though the >> > translation of 'self atexit: #sendSignalToPids' produces a surprising >> > result in this case, I would still say that is reasonable to expect >> > Smalltalk symbols and strings to both translate into C strings, and >> > it would not be reasonable to expect a simple C translator to do >> > enough type checking to figure out that in this particular case the >> > '#sendSignalToPids' should be treated as a function pointer rather >> > than as a string. >> > >> >> I concur not. As to me a least surprising behaviour for code generator >> would be to covert symbols to >> identifiers with same name, instead of literal strings. >> >> >> > The original method in UnixOSProcessPlugin is written as follows in >> > order to avoid this issue: >> > >> > ?? ?? ?? ??self cCode: 'atexit(sendSignalToPids)'. >> > >> >> the problem with above code that it doesn't tells code generator to >> keep sendSignalToPids method around, >> instead of pruning it since nobody using it. >> That's why in hydra i added this special asCIdentifier to not only >> convert symbol to identifier (instead of quoted C string) >> but also make sure that if given symbol matching the method name , >> then make sure that this method won't be pruned. > > I don't understand why this was a problem in hydra. The method is > referenced from #initialiseModule, and is not pruned by the code > generator for that reason. i'm not talking about this particular case. Sometimes the only reference where function is used is in passing an address to function. Which, if you don't have asCIdentifier cannot be detected, because its in cCode: clause. > >> >> And of course , when browsing the code i can see senders of it, while >> if i forced to use cCode: 'yaddayadda', >> it will hide the usage from our eyes. >> >> So, one way or another, but the less cCode: we have, the better. > > As a general rule, yes. In this specific case, no. > > I wrote the method that way for a reason, and it is correct as > written. It is correct because the code snippet has no meaningful > equivalent in interpreter simulation, it involves non-trivial > C variable type declarations, and it avoids hiding the intent of > the code behind mysterious slang translations. You can understand > how it works by reading the method in Smalltalk, and there is > no possibility of error due to "unexpected" C translation. > > I am not saying that writing "self atexit: #sendSignalToPids asSymbol" > is wrong, but you would be hard pressed to convince me that it is > easier to read and understand. > needless to say, that such pattern are quite common in smalltalk(s), for events, handlers , subscriptions etc etc > Note that the "self atexit: ..." change exists only in the oscog > branch. I don't know the motivation for that change, so maybe I'm > missing something. > no idea either.. i just happy that it works now :) > Dave > >> >> > I also note that the purpose of SlangBrowser is to make it easy to >> > review code like this while it is being written, so I guess that I >> > should get off my butt and get this working in the oscog branch one >> > of these days :-/ >> > >> > Dave >> > > -- Best regards, Igor Stasenko AKA sig. |
Re: Building OSProcessPlugin on macs
|
|
On Thu, Jul 07, 2011 at 02:30:13PM +0200, Igor Stasenko wrote: > > On 7 July 2011 14:22, David T. Lewis <[hidden email]> wrote: > > > > On Thu, Jul 07, 2011 at 05:36:51AM +0200, Igor Stasenko wrote: > >> > >> the problem with above code that it doesn't tells code generator to > >> keep sendSignalToPids method around, > >> instead of pruning it since nobody using it. > >> That's why in hydra i added this special asCIdentifier to not only > >> convert symbol to identifier (instead of quoted C string) > >> but also make sure that if given symbol matching the method name , > >> then make sure that this method won't be pruned. > > > > I don't understand why this was a problem in hydra. The method is > > referenced from #initialiseModule, and is not pruned by the code > > generator for that reason. > > i'm not talking about this particular case. Sometimes the only > reference where function is used is in passing an address to function. > Which, if you don't have asCIdentifier cannot be detected, because its > in cCode: clause. Oh, now I understand. Yes you are right. > > > > I am not saying that writing "self atexit: #sendSignalToPids asSymbol" > > is wrong, but you would be hard pressed to convince me that it is > > easier to read and understand. > > > well, it could be understood as passing a selector to perform it later.. > needless to say, that such pattern are quite common in smalltalk(s), > for events, handlers , subscriptions etc etc That's a fair point. > > > Note that the "self atexit: ..." change exists only in the oscog > > branch. I don't know the motivation for that change, so maybe I'm > > missing something. > > > no idea either.. i just happy that it works now :) > Thanks, me too :) Dave |
Re: Building OSProcessPlugin on macs
|
|
On 07.07.2011, at 17:00, David T. Lewis wrote: > On Thu, Jul 07, 2011 at 02:30:13PM +0200, Igor Stasenko wrote: >> >> On 7 July 2011 14:22, David T. Lewis <[hidden email]> wrote: >>> >>> On Thu, Jul 07, 2011 at 05:36:51AM +0200, Igor Stasenko wrote: >>> I am not saying that writing "self atexit: #sendSignalToPids asSymbol" >>> is wrong, but you would be hard pressed to convince me that it is >>> easier to read and understand. >>> >> well, it could be understood as passing a selector to perform it later.. >> needless to say, that such pattern are quite common in smalltalk(s), >> for events, handlers , subscriptions etc etc > > That's a fair point. I would like it best if only literal strings would be translated into C strings. Symbols should become identifiers. If that policy cannot be adopted for some reason, I like Igor's "asCIdentifier" better than "asSymbol". - Bert - |
Re: Building OSProcessPlugin on macs
|
|
In reply to this post by David T. Lewis
On Wed, Jul 6, 2011 at 8:28 PM, David T. Lewis <[hidden email]> wrote:
Not so. Strings and symbols are only used interchangeably in type declarations and these can be put in pragmas. So <var: #theFP type: #'char *'>
is equivalent to <var: 'theFP' type: 'char *'> since Slang merely transcribes the characters in either the string or symbol.
But in code a symbol should be different to a string. A string should translate to a string, and a symbol should translate to a name. e.g. in self sizeof: #SQFile it is really dumb of Slang to translate this as sizeof("SQFile"). Since we're always talking about literal symbols and literal strings it is always possible for the programmer to use a literal string where they mean there to be a string, and not a symbol. Further, this change would not affect any of the existing uses of symbols and strings for type declarations.
So I think that there is a general expectation I disagree. Its a historical accident that we should agree to clean-up. In A context which arises throughout the VM with indirect function calls, with sizes of types, etc. So even though the I disagree. But I've been using the #asSymbol workaround since I want consensus before making any change.
This isn't a good approach since one can neither look for senders of #atexit: nor #sendSignalToPids, nor can one simulate its execution. In general the use of a string argument to cCode: should be ruthlessly stamped out whereever possible.
-- best, Eliot |
Re: Building OSProcessPlugin on macs
|
|
In reply to this post by Igor Stasenko
On Wed, Jul 6, 2011 at 8:36 PM, Igor Stasenko <[hidden email]> wrote:
+1
+1000
-- best, Eliot |
Re: Building OSProcessPlugin on macs
|
|
In reply to this post by Igor Stasenko
On Thu, Jul 07, 2011 at 04:18:01AM +0300, Igor Stasenko wrote: > > Aha.. so failing tests are because fork is unavailable. > David, could you change the relevant tests to not fail but rather pass > or 'expected fail' > when running on macs? > because i'd like to know how well it is, and to know that i wanna see > clear picture what are problems if any. Making them 'expected fail' on macs sounds reasonable, although I don't have a mac so I can't look at it right now. Note that pretty much all of the tests would be 'expected fail' on Windows ;) Dave |
Re: Building OSProcessPlugin on macs
|
|
In reply to this post by Eliot Miranda-2
On Thu, Jul 07, 2011 at 10:20:41AM -0700, Eliot Miranda wrote: > > On Wed, Jul 6, 2011 at 8:28 PM, David T. Lewis <[hidden email]> wrote: > > > So I think that there is a general expectation > > that either a symbol or a string would translate to C as a string. > > I disagree. Its a historical accident that we should agree to clean-up. > OK, I'm convinced. Someone should give it a try and do a 'diff -r' on all the generated code to see if anything breaks. Dave |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |