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

Re: [Pharo-dev] Slice 12324

by Stephan Eggermont

I tried committing/copying an updated slice, but am unable to get it into the Pharo30Inbox, even though I can copy packages in it. Is this a known issue? Stephan

Dec. 4, 2013

Re: [Pharo-dev] Slice 12324

by Esteban Lorenzano

nope... you should be able to commit the slice without problems. On Wed, Dec 4, 2013 at 1:40 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > I tried committing/copying an updated slice, but am unable to get it into > the Pharo30Inbox, > even though I can copy packages in it. Is this a known issue? > > Stephan >

Dec. 4, 2013

Re: [Pharo-dev] Grease conflicts #packages with RPackage

by Esteban Lorenzano

senders of what? I can use senders. On Wed, Dec 4, 2013 at 1:34 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Esteban wrote: > >sorry, but I still do not understand why this is a problem. > >can you elaborate why it should not be more implementations? > > It breaks the system. You can no longer use senders. > So currently, all Moose and Seaside based 3.0 images are > somewhat unusable. > > Stephan > >

Dec. 4, 2013

Re: [Pharo-dev] Grease conflicts #packages with RPackage

by Stephan Eggermont

Esteban wrote: >sorry, but I still do not understand why this is a problem. >can you elaborate why it should not be more implementations? It breaks the system. You can no longer use senders. So currently, all Moose and Seaside based 3.0 images are somewhat unusable. Stephan

Dec. 4, 2013

Re: [Pharo-dev] 12259: FileSystem memory reads writesusing a binary stream by default

by Max Leske

Let me see what I can come up with. On 03.12.2013, at 19:36, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Thanks Max for the report. Do you have an idea on how we could solve the problem ? The previous behaviour was not acceptable either because the streams that came out of a memory filesystem were the only ones with binary content > > On Dec 3, 2013 5:35 PM, "Max Leske" <maxleske(a)gmail.com> wrote: > Damien, Marcus > > this change breaks a lot of things in FileSystem-Git. I donât disagree with the idea that reading characters should be default (one could argue about itâ¦) but your change makes it IMPOSSIBLE to read bytes because unprintable characters are discarded! So if my ByteArray is a NULL terminated string, for instance, I can not check for the NULL termination anymore. > > Cheers, > Max

Dec. 4, 2013

Re: [Pharo-dev] Grease conflicts #packages with RPackage

by Marcus Denker

On 04 Dec 2013, at 13:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > and why is a problem for us and for grease? > because people want to say MyClass package and get back the RPackage that the class is in... > > > On Wed, Dec 4, 2013 at 1:09 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Because many times you sent class side #packages as part of RPackage framework. But...if you have other class side #packages that answer something different...then you are screw. > See my original post: http://forum.world.st/Re-Grease-conflicts-packages-with-RPackage-td4706911.… > > > On Wed, Dec 4, 2013 at 8:54 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > sorry, but I still do not understand why this is a problem. > can you elaborate why it should not be more implementations? > > Esteban > > > On Tue, Dec 3, 2013 at 3:25 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > I could copy the separate packages, but not the slice. > > Please note that the added test is expected to fail on all builds containing Grease-Core. > > Stephan > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 4, 2013

Re: [Pharo-dev] Grease conflicts #packages with RPackage

by Mariano Martinez Peck

For us because there are 4 or 5 class side #packages IN PHARO, not grease. On Wed, Dec 4, 2013 at 9:11 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > and why is a problem for us and for grease? > > > > On Wed, Dec 4, 2013 at 1:09 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Because many times you sent class side #packages as part of RPackage >> framework. But...if you have other class side #packages that answer >> something different...then you are screw. >> See my original post: >> http://forum.world.st/Re-Grease-conflicts-packages-with-RPackage-td4706911.… >> >> >> On Wed, Dec 4, 2013 at 8:54 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: >> >>> sorry, but I still do not understand why this is a problem. >>> can you elaborate why it should not be more implementations? >>> >>> Esteban >>> >>> >>> On Tue, Dec 3, 2013 at 3:25 PM, Stephan Eggermont <stephan(a)stack.nl>wrote: >>> >>>> I could copy the separate packages, but not the slice. >>>> >>>> Please note that the added test is expected to fail on all builds >>>> containing Grease-Core. >>>> >>>> Stephan >>>> >>>> >>>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > -- Mariano http://marianopeck.wordpress.com

Dec. 4, 2013

Re: [Pharo-dev] Grease conflicts #packages with RPackage

by Esteban Lorenzano

and why is a problem for us and for grease? On Wed, Dec 4, 2013 at 1:09 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Because many times you sent class side #packages as part of RPackage > framework. But...if you have other class side #packages that answer > something different...then you are screw. > See my original post: > http://forum.world.st/Re-Grease-conflicts-packages-with-RPackage-td4706911.… > > > On Wed, Dec 4, 2013 at 8:54 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> sorry, but I still do not understand why this is a problem. >> can you elaborate why it should not be more implementations? >> >> Esteban >> >> >> On Tue, Dec 3, 2013 at 3:25 PM, Stephan Eggermont <stephan(a)stack.nl>wrote: >> >>> I could copy the separate packages, but not the slice. >>> >>> Please note that the added test is expected to fail on all builds >>> containing Grease-Core. >>> >>> Stephan >>> >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 4, 2013

Re: [Pharo-dev] Grease conflicts #packages with RPackage

by Mariano Martinez Peck

Because many times you sent class side #packages as part of RPackage framework. But...if you have other class side #packages that answer something different...then you are screw. See my original post: http://forum.world.st/Re-Grease-conflicts-packages-with-RPackage-td4706911.… On Wed, Dec 4, 2013 at 8:54 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > sorry, but I still do not understand why this is a problem. > can you elaborate why it should not be more implementations? > > Esteban > > > On Tue, Dec 3, 2013 at 3:25 PM, Stephan Eggermont <stephan(a)stack.nl>wrote: > >> I could copy the separate packages, but not the slice. >> >> Please note that the added test is expected to fail on all builds >> containing Grease-Core. >> >> Stephan >> >> >> > -- Mariano http://marianopeck.wordpress.com

Dec. 4, 2013

Re: [Pharo-dev] Unifying Testing Ideas

by Attila Magyar

I'll try. I think mocking the file system and other third party, low abstraction stuffs can lead brittle tests and duplications. For example we want to store certificate files in pem format in the file system. Mocking out the fs would look like this: file = mock('file') File.should_receive(:open).with("filename", "w").and_yield(file) file.should_receive(:write).with("pem content of the cert") I don't know ruby too well, so don't know how many different ways I can write some content into a file, but I suspect there are lot. E.g. if I change the "write" to "puts" the test will fail, even if the functionality is still working. That's why it is brittle. There are also some duplication between the test and the production code, because both has the very same structure. Introducing a CertificateStore as a dependency with a more abstract interface solves this problem and simplifies the test as well. cert_store.should_receive(:store_cert).with(certificate) I'm no longer passing the content as a string but as certificate object, and I don't care about the low level details of the storing mechanism. As a matter of fact the storage may store the cert in an other location than the file system, and the client won't care. Then the question is, how do I test the certificate store? And this is the point where I would switch from mocking to integration test. Because I want to be sure that I understood the file system api correctly, and it writes the file physically to the disk. The previous test didn't provide this confidence. Using an inmemory file system to speed up the test is ok imho, but there is a risk of course that it behaves differently than the real one. Personally I wouldn't use in memory file system in a test like this. On Wed, Dec 4, 2013 at 11:31 AM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > > Can you give an example of what you mean? > > Being about to stub out the file system, or the clock, seem like > extremely useful things to do. (See https://github.com/defunkt/fakefs > for instance.) > > frank > >

Dec. 4, 2013