January 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] where can I find the athens player?

by Esteban Lorenzano

ahhh, btw, you don't need the chipmunk library to use the AthensPlayground, just the cairo lib :) On Jan 26, 2013, at 5:26 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > The AthensPlayground is part of the Storm project, you can find here: http://smalltalkhub.com/#!/~estebanlm/Storm > > I *think* the metacello config is in sync with sources so you just need to follow instruction. If you have any problem please let me know :) > > Esteban > > On Jan 26, 2013, at 1:01 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi esteban >> >> where is your code to try athens? >> It would be good to move all the code to >> Pharo/Athens >> >> >> Stef >> >

Jan. 26, 2013

Re: [Pharo-project] [update 2.0] #20491

by StÃ©phane Ducasse

Torsten I took the 20486 from the ci server and did an update and I got no problem at all. So I have no idea from where the problem is coming. Stef On Jan 26, 2013, at 12:25 PM, Torsten Bergmann wrote: > I get a merge problem (3 conflicts) when updating from a Pharo-20486.image: > > KeyChain-StephaneDucasse.29

Jan. 26, 2013

Re: [Pharo-project] where can I find the athens player?

by Esteban Lorenzano

Hi, The AthensPlayground is part of the Storm project, you can find here: http://smalltalkhub.com/#!/~estebanlm/Storm I *think* the metacello config is in sync with sources so you just need to follow instruction. If you have any problem please let me know :) Esteban On Jan 26, 2013, at 1:01 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi esteban > > where is your code to try athens? > It would be good to move all the code to > Pharo/Athens > > > Stef >

Jan. 26, 2013

Re: [Pharo-project] [update 2.0] #20491

by StÃ©phane Ducasse

Strange. I do not see why this can happen. Stef On Jan 26, 2013, at 12:25 PM, Torsten Bergmann wrote: > I get a merge problem (3 conflicts) when updating from a Pharo-20486.image: > > KeyChain-StephaneDucasse.29

Jan. 26, 2013

Re: [Pharo-project] NativeBoostFFI out parameters passing pointers back and forth is confusing...

by Ciprian Teodorov

Hi Stefan, I've just committed a little modification to TalkFFI to automatically generate subclasses of NBExternalObject for definitions like: typedef struct my_struct my_struct_t; void fct(my_struct_t *inArg) the ffi call is void fct(MyStructTPtr inArg). This gives us type-checking and simplifies the usage pattern, that u have presented, to: |headHandle path repo name| repo := LG2GitRepositoryPtr new. path := NBExternalAddress fromString: '/Users/ciprian/github/local/enso'. LG2RepositoryH uniqueInstance repository_open: repo path: path. headHandle := LG2GitReferencePtr new. LG2RepositoryH uniqueInstance repository_head: headHandle repo: repo. name := LG2RefsH uniqueInstance reference_name: headHandle. name readString. Cheers, On Fri, Jan 25, 2013 at 9:45 PM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > Hi Ciprian: > > On 25 Jan 2013, at 20:58, Ciprian Teodorov wrote: > > > repo := NBExternalObject new. > [...] > > > repository_open: out path: path > > ^self call: #(NBInt32 git_repository_open(NBExternalObject * out, > NBCharacterType * path)) options: #( ) > > > > Notice that when using NBExternalObject one level of indirection is gone > so git_repository ** becomes NBExternalObject * > > Indeed, much nicer. > > I am now using type aliases such as: > #(git_repository_ptr NBExternalObject > git_reference_ptr NBExternalObject) > > With a signature such as: > ^self call: #(int git_repository_open(git_repository_ptr * handle, char * > path)) > > That stays close to the C, and tells me what the pointer are. > > And with the NBExternalObject it works nicely. > > Thanks a lot! > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- 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. 26, 2013

[Pharo-project] [update 2.0] #20491

by Torsten Bergmann

Jan. 26, 2013

Re: [Pharo-project] where can I find the latest athens?

by Alexandre Bergel

I checked: https://ci.inria.fr/rmod/job/Athens/? There is no link for a one-click distribution? Apparently the VM is not available? Cheers, Alexandre On Jan 26, 2013, at 7:19 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > => #last works > => Igor you should add a description to the jenkins job with the basics :) > > On 2013-01-26, at 11:15, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> ok, no stable configuration defined ;) >> >> https://ci.inria.fr/rmod/job/Athens/18/console >> >> so trying #development >> >> >> On 2013-01-26, at 11:14, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> I just set up the jenkins job so we have one ;) >>> Check the ci configuration: >>> >>> ./vm.sh $JOB_NAME.image config $REPO ConfigurationOfAthens --install=1.4 >>> >>> so maybe I should change that to stable... then again, this is not my job either I think ;) >>> >>> On 2013-01-26, at 01:03, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: >>> >>>> I opened the MC repository of Athens in the image that we can get from the ci >>>> and I do not understand why there are lot of packages that are not the loaded. >>>> Are they current development? >>>> Is the CI image really holding the latest stable version? >>>> >>>> Stef > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 26, 2013

[Pharo-project] [update 2.0] #20491

by StÃ©phane Ducasse

20491 ----- Issue 7327: RBParser should raise SyntaxErrorNotification. Thanks Marcus Denker http://code.google.com/p/pharo/issues/detail?id=7327 Issue 7331: NewList update :)Thanks Benjamin van Ryseghem http://code.google.com/p/pharo/issues/detail?id=7327 Diff information: http://ss3.gemstone.com/ss/Pharo20/Spec-Core-StephaneDucasse.76.diff http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-StephaneDucasse.759.di… http://ss3.gemstone.com/ss/Pharo20/NewList-StephaneDucasse.17.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-StephaneDucasse.1334.diff http://ss3.gemstone.com/ss/Pharo20/AST-Core-StephaneDucasse.111.diff

Jan. 26, 2013

[Pharo-project] tuesday we will do a coding sprint here at Santiago

by StÃ©phane Ducasse

Hi guys We will do a coding sprint here at Santiago @ DCC (Pleaid building) http://pleiad.dcc.uchile.cl We should have a list of issue to fix :) I will check the issues in the bug tracker but any help, wishes from this sprint is welcome. Stef

Jan. 26, 2013

Re: [Pharo-project] OSProcess updated for Pharo 2.0

by Frank Shearar

On 26 Jan 2013, at 1:59, "David T. Lewis" <lewis(a)mail.msen.com> wrote: > On Sat, Jan 26, 2013 at 08:50:43AM +0800, Ben Coman wrote: >> David T. Lewis wrote: >>> On Fri, Jan 18, 2013 at 03:28:10PM +0100, Damien Cassou wrote: >>> >>>> you don't need FileSystem-Legacy if you use OSProcess from Coral: >>>> >>>> Gofer new >>>> squeaksource3: 'coral'; >>>> package: 'OSProcess'; >>>> load. >>>> >>>> >>> >>> OSProcess and CommandShell-Piping should now load cleanly in Pharo 2.0. >>> >>> The latest versions are OSProcess-dtl.75 and CommandShell-Piping-dtl.13 >>> in the SqueakSource repositories for OSProcess and CommandShell. >>> >>> Thanks to Damien Cassou for doing the original work for OSProcess support >>> in Coral. I adapted his work so it will now load in both Squeak and Pharo. >>> >>> Unit test notes: >>> >>> The AioEventHandlerTestCase failures are due to AioPlugin not included in >>> the VM. I expect the tests will pass if AioPlugin is added to VM builds. >>> >> Just general curiosity, is there a way to have a test queued to run >> first which tests for the plug-in, and if it fails the remaining tests >> become "expected failures" rather than "failures". > > Yes, you could do this by implementing #expectedFailures to check for the > plugin and answer a different set of selectors depending on what it finds. > > It all depends on what you mean by an "expected failure". To me, failing > to find the plugin is not an expected failure. It means that something is > wrong, and somebody should do something about it. In this case it serves > as a reminder to include AioPlugin in the next VM build. After all, that > is one of the reasons for doing all those tests in the first place :) > > A related question is how to handle failures when running on some other OS > (e.g. Windows) where OSProcess is really not meaningfully implemented. In > that case, the failures really are expected. I allow them to fail because > I wrote the tests for my own benefit as the developer (in that context, > a feature that does not work on Windows really should fail the test, as it > shows what still needs to be implemented), but running the tests as part > of a larger suite on a range of operating systems would be a problem. I > don't really have any answer for that. I suppose I could enumerate all the > things that are not expected to work on a non-unix system, but that sounds > like a lot of work (and no fun) to me. > > Dave There's still value in tests that fail on Windows, and in an ideal world those folks who need OSProcess on Windows (all of them, surely!) could then go look at the CI job to see what works and what not, and submit patches to the maintainer! frank > >>> Many test rely on #forkSqueak to create cooperating OS processes for the >>> tests. These tests fail on Cog, although this does not affect basic >>> functionality of OSProcess itself. >>> >>> UnixProcessAccessorTestCase>>testRedirectStdOutTo fails due to a problem >>> introduced in the oscog branch of the OSProcessPlugin. This should be fixed >>> in the plugin but is a minor concern and does not affect normal usage >>> of OSProcess. >>> >>> Dave >>> >>> >>> >>> >> >

Jan. 26, 2013