- Pharo-dev - lists.pharo.org

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

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

by Esteban Lorenzano

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 > > >

Dec. 4, 2013

Re: [Pharo-dev] Unifying Testing Ideas

by Frank Shearar

On 4 December 2013 11:34, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > The reason for my initial hesitation was that... in rspec, it is easy to > stub out global class objects and... I don't think this is the right > solution for the problem. > > > Ha ha, you were right to be cautious. I've been thinking for offer a year > about how to do that without method wrappers. But I will control myself in > your project ;) It's still a work in progress, but Squeak's Environments ought to provide this: your test runs in a custom, temporary Environment into which you import your own DateAndTime or FileReference or whatever. Code inside the Environment just calls DateAndTime, blissfully unaware that it's calling your custom mocked implementation. frank

Dec. 4, 2013

Re: [Pharo-dev] [Pharo-users] Building Pharo using Interpreter Class

by Kirstin Heidler

Hello Stephane, he tried several times last thursday. He also tried using Nabble which did not work. Nabble produced some error about him not having permission to post. However in the interface of Nabble it displays him as a well registered user, as far as I can judge. This is one of the headers when he tried to send to the mailing list: -------- Original-Nachricht -------- Betreff: Building Pharo without using only Interpreter class Datum: Thu, 28 Nov 2013 16:18:13 +0100 Von: Dimitri Korsch <dimitri.korsch(a)student.hpi.uni-potsdam.de> An: <pharo-dev(a)lists.pharo.org> Kopie (CC): Kirstin Heidler <kirstin.heidler(a)student.hpi.uni-potsdam.de>, <nicco.kunzmann(a)student.hpi.uni-potsdam.de> Maybe it didn't work becuase Nicco and I were in CC? Kirstin Am 03.12.2013 20:58, schrieb StÃ©phane Ducasse: > Hello kirstin > > why dimitri is not able to post? can you tell us more? > > Stef > > On Dec 3, 2013, at 1:17 PM, Kirstin Heidler <kirstin.heidler(a)student.hpi.uni-potsdam.de> wrote: > >> My freind Dimitri was not able to post his message. I am working with him on this. >> >> _______________________________________________________________________________ >> >> Hello, >> >> as part of a Seminar in the University im trying to build the PharoVM. >> According to the README file here ([1]) I was able to generate and to >> build the VM successfully. >> >> Now I would like to build the VM without Cog or Stack-to-Register >> optimizations... The problem here is, that I could not find any config >> class (which is a subclass of CPlatformConfig), that provides the right >> configurations and allows to build the VM without errors. I have tried >> to modify PharoUnixConfig(because it was the default config class), but >> unfortunately the build failes when the compiler tries to compile >> gcc3x-interp.c. >> >> Could somebody help me with this problem? How should I configure my own >> Config class? >> >> Basically our Group tries to implement an object table in Pharo and we >> want to use (and modify) the basic Interpreter class. >> >> >> >> [1] https://github.com/pharo-project/pharo-vm >> >> >> Best regards, >> Dimitri Korsch >> >

Dec. 4, 2013

Re: [Pharo-dev] Unifying Testing Ideas

by Sean P. DeNigris

The reason for my initial hesitation was that... in rspec, it is easy to stub out global class objects and... I don't think this is the right solution for the problem.Â Ha ha, you were right to be cautious. I've been thinking for offer a year about how to do that without method wrappers. But I will control myself in your project ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Unifying-Testing-Ideas-tp4726787p4727283.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 4, 2013