- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] Headless support for Cog Cocoa VM

by Ciprian Teodorov

Hi Mariano, on MacOS 10.6.8 doing ./CogVM-release-noflash-noArgs.app/Contents/MacOS/CogVM Pier3.image does not work, I get Illegal instruction... the same with ./CogVM-release-noflash-noArgs.app/Contents/MacOS/CogVM --headless Pier3.image if i try using open CogVM-release-noflash-noArgs.app Pier3.image, it works but It's not headless, however when looking in the info.plist the key you have mentioned is there <key>LSBackgroundOnly</key> <true/> On Sat, Jan 19, 2013 at 2:26 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sat, Jan 19, 2013 at 7:24 AM, Stephan Eggermont <stephan(a)stack.nl>wrote: > >> This doesn't work >> >> >> open CogVM-release-noflash-noArgs.app Pier3.image & >> >> > Which OSX version are you using? > > > >> >> Jan 19 11:20:51 Stephan-Eggermonts-iMac >> [0x0-0x2f92f9].org.seaside-project[36832]: This interpreter (vers. 6502) >> cannot read image file (vers. 6505). >> Jan 19 11:20:51 Stephan-Eggermonts-iMac >> [0x0-0x2f92f9].org.seaside-project[36832]: Press CR to quit... >> Jan 19 11:20:52 Stephan-Eggermonts-iMac ReportCrash[36836]: Failed to >> create CSSymbolicatorRef for launchd >> Jan 19 11:20:52 Stephan-Eggermonts-iMac >> com.apple.launchd.peruser.501[207] >> ([0x0-0x2fa2fa].org.squeakfoundation.Squeak[36835]): Job appears to have >> crashed: Segmentation fault >> Jan 19 11:20:52 Stephan-Eggermonts-iMac ReportCrash[36836]: Saved crash >> report for launchd[36835] version ??? (???) to >> /Users/stephan/Library/Logs/DiagnosticReports/launchd_2013-01-19-112052_Stephan-Eggermonts-iMac.crash >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Jan. 19, 2013

Re: [Pharo-project] [ANN] Headless support for Cog Cocoa VM

by Mariano Martinez Peck

On Sat, Jan 19, 2013 at 7:24 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > This doesn't work > > > open CogVM-release-noflash-noArgs.app Pier3.image & > > Which OSX version are you using? > > Jan 19 11:20:51 Stephan-Eggermonts-iMac > [0x0-0x2f92f9].org.seaside-project[36832]: This interpreter (vers. 6502) > cannot read image file (vers. 6505). > Jan 19 11:20:51 Stephan-Eggermonts-iMac > [0x0-0x2f92f9].org.seaside-project[36832]: Press CR to quit... > Jan 19 11:20:52 Stephan-Eggermonts-iMac ReportCrash[36836]: Failed to > create CSSymbolicatorRef for launchd > Jan 19 11:20:52 Stephan-Eggermonts-iMac com.apple.launchd.peruser.501[207] > ([0x0-0x2fa2fa].org.squeakfoundation.Squeak[36835]): Job appears to have > crashed: Segmentation fault > Jan 19 11:20:52 Stephan-Eggermonts-iMac ReportCrash[36836]: Saved crash > report for launchd[36835] version ??? (???) to > /Users/stephan/Library/Logs/DiagnosticReports/launchd_2013-01-19-112052_Stephan-Eggermonts-iMac.crash > -- Mariano http://marianopeck.wordpress.com

Jan. 19, 2013

Re: [Pharo-project] [ANN] Headless support for Cog Cocoa VM

by Mark Lee Smith

Can you try â $ open -a CogVM-release-noflash-noArgs.app Pier3.image or $ ./CogVM-release-noflash-noArgs.app/Contents/MacOS/CogVM Pier3.image On 19 Jan 2013, at 10:24, Stephan Eggermont <stephan(a)stack.nl> wrote: > This doesn't work > > > open CogVM-release-noflash-noArgs.app Pier3.image & > > > Jan 19 11:20:51 Stephan-Eggermonts-iMac [0x0-0x2f92f9].org.seaside-project[36832]: This interpreter (vers. 6502) cannot read image file (vers. 6505). > Jan 19 11:20:51 Stephan-Eggermonts-iMac [0x0-0x2f92f9].org.seaside-project[36832]: Press CR to quit... > Jan 19 11:20:52 Stephan-Eggermonts-iMac ReportCrash[36836]: Failed to create CSSymbolicatorRef for launchd > Jan 19 11:20:52 Stephan-Eggermonts-iMac com.apple.launchd.peruser.501[207] ([0x0-0x2fa2fa].org.squeakfoundation.Squeak[36835]): Job appears to have crashed: Segmentation fault > Jan 19 11:20:52 Stephan-Eggermonts-iMac ReportCrash[36836]: Saved crash report for launchd[36835] version ??? (???) to /Users/stephan/Library/Logs/DiagnosticReports/launchd_2013-01-19-112052_Stephan-Eggermonts-iMac.crash

Jan. 19, 2013

[Pharo-project] Do you plan for Pharo2.0 migrate main repositories to SmalltalkHub?

by Denis Kudriashov

Hello Squeaksource seems down. I notice this when try open configuration browser. It hanges on squeaksource metacello repository reading. And squeaksource is deprecated resource. So do you plan for Pharo 2.0 to migrate main repositories to SmalltalkHub? Best regards, Denis

Jan. 19, 2013

Re: [Pharo-project] squeaksource down?

by Ciprian Teodorov

it look down for me too :( On Sat, Jan 19, 2013 at 12:54 PM, Denis Kudriashov <dionisiydk(a)gmail.com>wrote: > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Jan. 19, 2013

[Pharo-project] squeaksource down?

by Denis Kudriashov

Jan. 19, 2013

Re: [Pharo-project] Class initialisation after loading

by Frank Shearar

On 19 January 2013 02:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Fri, Jan 18, 2013 at 2:38 PM, Frank Shearar <frank.shearar(a)gmail.com> > wrote: >> >> On 18 January 2013 21:49, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > phhh, let me try again :) >> > >> > >> > On Fri, Jan 18, 2013 at 8:47 AM, Frank Shearar <frank.shearar(a)gmail.com> >> > wrote: >> >> >> >> On 17 January 2013 17:45, Eliot Miranda <eliot.miranda(a)gmail.com> >> >> wrote: >> >> > >> >> > >> >> > >> >> > On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko <siguctua(a)gmail.com> >> >> > wrote: >> >> >> >> >> >> After some thought i decided to contribute my 2cents. >> >> >> >> >> >> First, i think it is impossible to introduce a (re)initialization >> >> >> logic which would suit all different scenarios. >> >> >> Because it is really depends on what is stored in class variables >> >> >> and/or >> >> >> pools >> >> >> and if you add subclasses and then instances into the soup, you >> >> >> might >> >> >> end up with something >> >> >> which is really hard to safely reinitialize, because it may have >> >> >> some >> >> >> inconsistent state at different stages >> >> >> of initialization. It also, sometimes an order of initialization is >> >> >> important. >> >> > >> >> > >> >> > Yes, but on *can* write idempotent class initialization code. So >> >> > that >> >> > if >> >> > the system does reinitialize on every load old code may break until >> >> > its >> >> > fixed, but new code will have the advantage of always being correctly >> >> > initialized. Note that in the VMMaker class reinitializations of the >> >> > core >> >> > VM classes (the interpreter, garbage collector, jit, etc) are done >> >> > *on >> >> > each >> >> > launch of the simulator*, and *each vm generation*, let alone on each >> >> > package load :). [ I'm not recommending this :) ]. >> >> > >> >> > One thing I do is when creating singletons for sentinels etc I check >> >> > whether >> >> > they've been initialized. e.g. >> >> > >> >> > initialize >> >> > Sentinel ifNil: [Sentinel := Object new] >> >> >> >> Knowing full well that I know next to nothing about concurrency in the >> >> image, and so realising that this might be a complete non-issue: lazy >> >> initialization and concurrency do not mix well. >> > >> > >> > Agreed, but the two can be decoupled. For example one can build the >> > state >> > and then assign it. Assignment is currently atomic so there are no >> > multicore issues here (yet :) ). Further, assignments are not >> > suspension >> > points so a sequence of (just) assignments are guaranteed to occur >> > without >> > interruption. And (I'm sure you realize, for give the pedantry) the >> > above >> > example isn't lazy, it is eager. It simply refuses to create another >> > Sentinel if one exists already. >> >> So because of the assignment guarantees we won't have two processes >> entering the ifNil: block? (I'll try extract one foot from my mouth >> and maybe replace it with another...) >> >> In this particular case things seem pretty innocuous: let's say two >> processes enter the #initialize. They both manage to enter the ifNil: >> (I'm aware this is compiled away to jumps, but the impact of this I >> don't know) through a time-of-check-time-of-use race, and you end up >> generating two objects. But one's simply lost. As long as references >> to Sentinel don't escape the class, no one need know anything at all. > > > right. but good point. i hadn't thought of this case. the scenarios i'm > thinking of are those where one is loading/updating a monticello or fuel > package or similar or redefining a class initialize method. in these > scenarios there's only likely to be one thread of control running the > initialize. I've been bitten too many times not to be leery of that particular case :). I had a nasty bug with a lazy initialisation in a 3rd party library where a TCP server kept a thread pool. If the thread pool was nil it would make a new one (so the Delphi equivalent of f ifNil: [f := blah]). On application shutdown, a thing running in that threadpool could call back to the TCP server. In particular, the TCP server would ask all threads to terminate and then nil the pool... and one of the threads would call back and reinitialise a whole new threadpool. The last thing the application did was wait for all threads to finish, and knew this by decrementing a counter. Only that cause-a-new-threadpool thread would try decrement the counter of a brand new threadpool. The application would happily wait forever for a notification from a thread that was long dead! The solution was simplicity itself: strip out the lazy initialization, and you don't get a second threadpool accidentally made. frank >> frank >> >> >> But I do agree with your sentiment: idempotency is highly desirable, >> >> and somehow forcing non-idempotent class initialisation to fail >> >> quickly and noisily sounds like a good plan. >> >> >> >> frank >> > >> > -- >> > best, >> > Eliot >> > > > > -- > best, > Eliot

Jan. 19, 2013

Re: [Pharo-project] [ANN] Headless support for Cog Cocoa VM

by Stephan Eggermont

This doesn't work open CogVM-release-noflash-noArgs.app Pier3.image & Jan 19 11:20:51 Stephan-Eggermonts-iMac [0x0-0x2f92f9].org.seaside-project[36832]: This interpreter (vers. 6502) cannot read image file (vers. 6505). Jan 19 11:20:51 Stephan-Eggermonts-iMac [0x0-0x2f92f9].org.seaside-project[36832]: Press CR to quit... Jan 19 11:20:52 Stephan-Eggermonts-iMac ReportCrash[36836]: Failed to create CSSymbolicatorRef for launchd Jan 19 11:20:52 Stephan-Eggermonts-iMac com.apple.launchd.peruser.501[207] ([0x0-0x2fa2fa].org.squeakfoundation.Squeak[36835]): Job appears to have crashed: Segmentation fault Jan 19 11:20:52 Stephan-Eggermonts-iMac ReportCrash[36836]: Saved crash report for launchd[36835] version ??? (???) to /Users/stephan/Library/Logs/DiagnosticReports/launchd_2013-01-19-112052_Stephan-Eggermonts-iMac.crash

Jan. 19, 2013

Re: [Pharo-project] [Pharo-users] [ANN] Headless support for Cog Cocoa VM

by StÃ©phane Ducasse

I would like thank officially Square [i] for this gift to the community. Thank again. Further work in this direction should be supported by the association and the consortium. Stef On Jan 18, 2013, at 8:14 PM, Mariano Martinez Peck wrote: > Hello there, > > For a long time, Pharaoers and Squakers have been asking for headless support in the Cocoa VMs just as we have with Carbon VMs. Carbon is becoming a legacy framework so people needed this. > > I wanted to thanks Square [i] International for sponsoring me to implement such a support. Not only have they sponsored the development but they have also agreed to release it under MIT license for the community. This headless support will be included in the official Pharo VM and will be, therefore, accessible to everybody. > > The project is not yet finished but I do have a demo/prototype that I wanted to share with you so that you can test it and give me feedback. This VM should only work starting at OSX 10.6. > > How to use it? Basically it works this way: to have headless, just edit the Info.plist and set the flag LSBackgroundOnly to 1 (add the key if it is not present): > > <key>LSBackgroundOnly</key> > <true/> > > When doing this, you don't even need the -headless anymore since, setting LSBackgroundOnly to 1, will cause the same effect (being the flag almost mandatory). If you don't want headless, put it to false or don't even put the key. If you don't set LSBackgroundOnly to 1 but send -headless, the VM will still be headless but you will see a little flash. If this flash bothers you, then set the flag. I am trying to get a way to avoid the "flash" while also avoiding to set LSBackgroundOnly to 1, but I still couldn't find it. Anyway, I think we can live with the current situation. > > How to test it? You should run the image with something like RFB or Seaside or whatever you can and then confirm if it is working even if you are headless. As a matter of testing, I saved an image with seaside running in the port 5555. You can get both, this Seaside image and the VM with headless from: https://www.dropbox.com/sh/r7qk49bxywk2xce/6N7-fdyx6V > So if you run the VM headless with that image and go to localhost:5555, you should see that Seaside is running. > > I would appreciate if you can test it. And please let me know in which version of OSX you tried. Of course, the more of you who can test it, the better. Notice that this VM was compiled with LLVM GCC 4.2 and it may have some problems in older OSX versions (but I think it shouldn't). I still couldn't compile a VM with GNU GCC 4.2 as I get a crash :( > > Expected results? In headless mode, anything should be displayed (no window, no menu, no item in the dock and nothing appear when switching apps). When running headfull, everything should be normal. > > Where is the code? The code I have modified to the VM is committed to my own fork of the VM: https://gitorious.org/~marianopeck/cogvm/marianopecks-blessed > Once the code is ready, I will do a pull request so that it can be integrated. > > Thanks everyone for the testing and feedback. Once again, thanks Square [i] International for sponsoring this great feature. Also thanks Esteban Lorenzano and Mark Smith for their incredible help. > > This was just the first prototype. I will keep you informed about possible progress. > > Best regards, > > -- > Mariano > http://marianopeck.wordpress.com

Jan. 19, 2013

Re: [Pharo-project] What are the messages where we should always have a super send?

by StÃ©phane Ducasse

Hi jan do you have an example of such tagging? Right now we are also thinking that we want three kinds of rules - 1 whose result is either zero because there is no problem or zero because we flag the false positives - 2 more fuzzy one where we should have flase positive defined per package - 3 more statistical rules (long methods, large number of instance variables) We are checking how we can find decent threshold values not generating thousands of warnings and also if we want to embed false positives for them too. May be they are just good for trend analysis and when you want to spot ugly code but you do not care to have them under your nose systematically. For the rules I'm also changing the implementation to make sure that we can customized the list of selectors, thresholds â¦. without having to recompile a method. This way people will be able to use their own conventions. Stef On Jan 18, 2013, at 6:24 PM, Jan Vrany wrote: > Hi Stef, > > while massaging SmallLint rules, you should also have look at > Smalltalk/X version of SmallLint [1] as we have ported > Pharo version and improved some rules. I have also added > a tagging system. That's useful for some rules are only > good if you want to ensure portable code, some are simply > broken and some stupid, etc. Having them properly classified > would help us all. > > Tell me once you finish your ride, I'll merge changes back :-) > > Jan > > [1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/ > > to checkout issue: > > cvs -d :pserver:cvs@cvs.smalltalk-x.de:/cvs/stx co stx/goodies/refactoryBrowser/lint/ > > > On 18/01/13 17:06, StÃ©phane Ducasse wrote: >> Hi >> >> While looking at SmallLint rule, I saw a rule that ensures that a given method always performs a >> super send. >> >> Here is the current list: >> >> ^#(#release #postCopy #preBuildWith: #postOpenWith: #noticeOfWindowClose: #initialize postBuildWith:) >> >> >> and I'm cleaning the list because there are VW elements such as postBuildWith: >> but do we have some other to add? >> >> Stef >> >> >> > >

Jan. 19, 2013