- Pharo-dev - lists.pharo.org

[Pharo-project] Image crash and doesn't generate crash.dmp in Windows

by Mariano Martinez Peck

Hi folks! My image is crashing but no crash.dmp is being generated. I am in windows. Does someone know what can be the cause? Thanks! Mariano

June 30, 2009

Re: [Pharo-project] FFI problem

by Mariano Martinez Peck

I crated the issue so that no to forget about it: http://code.google.com/p/pharo/issues/detail?id=908 Best, Mariano On Sun, Jun 28, 2009 at 3:56 AM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > Mariano Martinez Peck wrote: > >> Ok. Pharo people is in this mail. Let's wait if someone can help us. >> > > Please cc vm-dev on any responses. I'm not subscribed to the Pharo list. > > I don't know why in mi Windows machine the dump file is not generated :( >> > > It looks like the crash has two different ways of showing. In the first > situation, it crashes with a recursive DNU. In the second, it actually does > generate a crash dump (attached). The latter seems to happen when you try to > step through the code. > > Benoit St-Jean can you attach the complete dump file? >> >> I tried this in Linux and it doesn't crash my image. So, only windows :( >> > > Difficult to say. There is a good possibility that the problem is unrelated > to the FFI since I have been completely unable to reproduce the problem > elsewhere. > > Cheers, > - Andreas >

June 30, 2009

Re: [Pharo-project] creation of ReadWriteStream with #on:

by Damien Cassou

Hi Cyrille, 2009/6/30 Cyrille Delaunay <cy.delaunay(a)gmail.com>: > With both of your answers I understand that there was a problem and > apparently no good reason to have a ReadLimit set at 0. > That was my question, thank you :) > (anyway this problem should disapear when Nile will replace the actual > Stream hierarchy ;)) there are a lot of oddities in the stream hierarchy. You probably don't want to fix them manually, it requires a complete rewrite. Bye -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 30, 2009

Re: [Pharo-project] creation of ReadWriteStream with #on:

by Cyrille Delaunay

With both of your answers I understand that there was a problem and apparently no good reason to have a ReadLimit set at 0.That was my question, thank you :) (anyway this problem should disapear when Nile will replace the actual Stream hierarchy ;)) 2009/6/30 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > Well, my point was that by copying that, you don't set writeLimit, so > attempting to write to the ReadWriteStream results in an error... > (which is why I gave a test that both reads and writes instead of just > reading) > In that case, what's the point? It's functionality is then just the > same as a ReadStream. (Which is doubly confusing, seeing as it > inherits from WriteStream) > > so doing it your way, we'd have to do: > > on: aCollection > readLimit := aCollection size. > writeLimit := aCollection size. > position := 0. > self reset. > > instead of a straight copy. > > Btw, your version has a dependency on the super as well, mainly that > it defines the correct instvars. :) > Which version to prefer comes down to taste, I guess. > > Cheers, > Henry > > On Jun 30, 2009, at 3:54 35PM, Alexandre Bergel wrote: > > >> You haven't set the writeLimit by just copying PositionableStream > >> though, have you? > > > > I suggested to copy PositionableStream>>on: in ReadWriteStream: > > on: aCollection > > > > collection := aCollection. > > readLimit := aCollection size. > > position := 0. > > self reset > > > > Your implementation works well too, it has no duplication, but has a > > dependency over the implementation of the superclass. > > > > Cheers, > > Alexandre > > > > > >> > >> > >> > >> On Jun 30, 2009, at 3:00 46PM, Alexandre Bergel wrote: > >> > >>>> Put the readLimit at 0 make sense for a WriteStream ( with witch > >>>> your not supposed to read ) but when you create a ReadWriteStream > >>>> on > >>>> a collection you would be able to read what is already in the > >>>> collection, no? > >>>> I wonder why #on: has not been overriden in the instance side of > >>>> ReadWriteStream ? > >>>> Maybe it's not a good idea to create a ReadWriteStream with a > >>>> collection that already includes elements ? > >>> > >>> > >>> It looks like on: must be overridden in ReadWriteStream. > >>> With ReadStream I have: > >>> (ReadStream on: (1 to: 20)) next => 1 > >>> (ReadStream on: (1 to: 20)) next; next => 2 > >>> > >>> However, with ReadWriteStream, nil is returned, for the very problem > >>> you mentioned: > >>> (ReadWriteStream on: (1 to: 20)) next => nil > >>> > >>> If I cut and paste PositionnableStream>>on: in ReadWriteStream, > >>> then I > >>> have the behavior I expected: > >>> (ReadWriteStream on: (1 to: 20)) next => 1 > >>> (ReadWriteStream on: (1 to: 20)) next; next => 2 > >>> > >>> Cheers, > >>> Alexandre > >>> > >>> -- > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> Alexandre Bergel http://www.bergel.eu > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 30, 2009

Re: [Pharo-project] creation of ReadWriteStream with #on:

by Henrik Johansen

Well, my point was that by copying that, you don't set writeLimit, so attempting to write to the ReadWriteStream results in an error... (which is why I gave a test that both reads and writes instead of just reading) In that case, what's the point? It's functionality is then just the same as a ReadStream. (Which is doubly confusing, seeing as it inherits from WriteStream) so doing it your way, we'd have to do: on: aCollection readLimit := aCollection size. writeLimit := aCollection size. position := 0. self reset. instead of a straight copy. Btw, your version has a dependency on the super as well, mainly that it defines the correct instvars. :) Which version to prefer comes down to taste, I guess. Cheers, Henry On Jun 30, 2009, at 3:54 35PM, Alexandre Bergel wrote: >> You haven't set the writeLimit by just copying PositionableStream >> though, have you? > > I suggested to copy PositionableStream>>on: in ReadWriteStream: > on: aCollection > > collection := aCollection. > readLimit := aCollection size. > position := 0. > self reset > > Your implementation works well too, it has no duplication, but has a > dependency over the implementation of the superclass. > > Cheers, > Alexandre > > >> >> >> >> On Jun 30, 2009, at 3:00 46PM, Alexandre Bergel wrote: >> >>>> Put the readLimit at 0 make sense for a WriteStream ( with witch >>>> your not supposed to read ) but when you create a ReadWriteStream >>>> on >>>> a collection you would be able to read what is already in the >>>> collection, no? >>>> I wonder why #on: has not been overriden in the instance side of >>>> ReadWriteStream ? >>>> Maybe it's not a good idea to create a ReadWriteStream with a >>>> collection that already includes elements ? >>> >>> >>> It looks like on: must be overridden in ReadWriteStream. >>> With ReadStream I have: >>> (ReadStream on: (1 to: 20)) next => 1 >>> (ReadStream on: (1 to: 20)) next; next => 2 >>> >>> However, with ReadWriteStream, nil is returned, for the very problem >>> you mentioned: >>> (ReadWriteStream on: (1 to: 20)) next => nil >>> >>> If I cut and paste PositionnableStream>>on: in ReadWriteStream, >>> then I >>> have the behavior I expected: >>> (ReadWriteStream on: (1 to: 20)) next => 1 >>> (ReadWriteStream on: (1 to: 20)) next; next => 2 >>> >>> Cheers, >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 30, 2009

Re: [Pharo-project] [ANN] Fix to issue 825

by Douglas Brebner

Marcus Denker wrote: > On 30.06.2009, at 11:44, Douglas Brebner wrote: > >> Marcus Denker wrote: >>> I personally think that with today's resources (my laptop has 4GB >>> of Ram, not 256Kb), we should rethink some of the >>> design-desicions taken 30 years ago. But many people are >>> violently against this, fighting a battle by citing "embedded >>> systems". If one manages to convince them that "embedded" these >>> days does not equal "small", they mumble about "smart dust" and >>> obscure things just to be able to fight for hacks not needed >>> these days... >>> >>> Exploring new ways with the resources we have today does not mean >>> that everything needs to live in the image. It means that one >>> can affort to invest resources into very general, reusable >>> solution to problems like this. >> Didn't Tim change CompiledMethods so they referred to their source >> using a pointer so the source could be stored anywhere? >> > > Yes, Tim did some changes (in 1998) to make compiledMethods normal > objects that have a ByteArray for the bytecode and a normal instvar > for the pointer to the source. IMHO the way to go, but it was never > added to squeak... mostly because people feared the overhead (there > are 40.000 methods, so adding another 40.000 is indeed noticable, as > we have seen in 3.9 with the MethodProperties...). I so wish that had made it in. > I personally like this change, as it makes the implementation higher- > level and more OO, which I think is a good thing. I personally think > that "more OO" is better than "more compact", considering that a > laptop these days has 4GB (this is GIGABYTES) of RAM. Yes, it feels like an optimisation that simply isn't necessary any more. Worse, it makes it hard for tools to work on them. I can imagine quite a few tools that could be made with Tim style CompiledMethods. > I always wonder how Smaltalk would look like if it was disgned with > the same philosophy in 1976 that people apply today. Using the "but > it costs memory" philosphy that everyone favors today, Smalltalk > would never have been done in 1976 at all. Smalltalk (and Lisp too) have always looked to me like they were designed for future hardware rather than whatever was contemporary. Didn't Alan say something about that? The mind boggles at what a Smalltalk properly designed today would look like. Though I do believe it would feel similar to todays since the basic ideas of message passing and a live systems containing the tools would probably remain though on a much larger scale with multiple images working together. Personally, I feel that people are looking too hard at the artefacts like the image, the class structure and forgetting *why* they were built the way they were. >>> One interesting aspect of the source/changes "outside the image" >>> is that this problem of data that is not used often and thus can >>> live on disk vs. memory is a general one. Hacking it into the >>> system just for the sources is just that: a hack. Providing a >>> general, scalable way to let objects live on disk that are not >>> needed is much better, as everyone can than use it. The system >>> can use it for other resources (fonts, images...). Programmers >>> can use it to keep their domain data on disk automatically. >> >> You mean something like LOOM? I would love to have that :) >> > Yes! :-) I'd also like to be able to store on remote images or even internet sites. Something like Craigs Spoon perhaps :)

June 30, 2009

Re: [Pharo-project] creation of ReadWriteStream with #on:

by Alexandre Bergel

> You haven't set the writeLimit by just copying PositionableStream > though, have you? I suggested to copy PositionableStream>>on: in ReadWriteStream: on: aCollection collection := aCollection. readLimit := aCollection size. position := 0. self reset Your implementation works well too, it has no duplication, but has a dependency over the implementation of the superclass. Cheers, Alexandre > > > > On Jun 30, 2009, at 3:00 46PM, Alexandre Bergel wrote: > >>> Put the readLimit at 0 make sense for a WriteStream ( with witch >>> your not supposed to read ) but when you create a ReadWriteStream on >>> a collection you would be able to read what is already in the >>> collection, no? >>> I wonder why #on: has not been overriden in the instance side of >>> ReadWriteStream ? >>> Maybe it's not a good idea to create a ReadWriteStream with a >>> collection that already includes elements ? >> >> >> It looks like on: must be overridden in ReadWriteStream. >> With ReadStream I have: >> (ReadStream on: (1 to: 20)) next => 1 >> (ReadStream on: (1 to: 20)) next; next => 2 >> >> However, with ReadWriteStream, nil is returned, for the very problem >> you mentioned: >> (ReadWriteStream on: (1 to: 20)) next => nil >> >> If I cut and paste PositionnableStream>>on: in ReadWriteStream, >> then I >> have the behavior I expected: >> (ReadWriteStream on: (1 to: 20)) next => 1 >> (ReadWriteStream on: (1 to: 20)) next; next => 2 >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 30, 2009

Re: [Pharo-project] creation of ReadWriteStream with #on:

by Henrik Johansen

You haven't set the writeLimit by just copying PositionableStream though, have you? Perhaps: ReadWriteStream >> on: aCollection super on: aCollection. readLimit := aCollection size. would be a better idea? Intervals can't be stored into by the way, so using a RWStream on one doesn't make much sense ;) here's a more accurate example for RWStream: rws := ReadWriteStream on: (1 to: 20) asArray. [rws atEnd] whileFalse: [rws peek odd ifFalse: [rws nextPut: 0] ifTrue: [rws next]] And the collection will contain #(1 0 3 0 5 0 7 0 9 0 11 0 13 0 15 0 17 0 19 0), as expected. Cheers, Henry On Jun 30, 2009, at 3:00 46PM, Alexandre Bergel wrote: >> Put the readLimit at 0 make sense for a WriteStream ( with witch >> your not supposed to read ) but when you create a ReadWriteStream on >> a collection you would be able to read what is already in the >> collection, no? >> I wonder why #on: has not been overriden in the instance side of >> ReadWriteStream ? >> Maybe it's not a good idea to create a ReadWriteStream with a >> collection that already includes elements ? > > > It looks like on: must be overridden in ReadWriteStream. > With ReadStream I have: > (ReadStream on: (1 to: 20)) next => 1 > (ReadStream on: (1 to: 20)) next; next => 2 > > However, with ReadWriteStream, nil is returned, for the very problem > you mentioned: > (ReadWriteStream on: (1 to: 20)) next => nil > > If I cut and paste PositionnableStream>>on: in ReadWriteStream, then I > have the behavior I expected: > (ReadWriteStream on: (1 to: 20)) next => 1 > (ReadWriteStream on: (1 to: 20)) next; next => 2 > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 30, 2009

Re: [Pharo-project] creation of ReadWriteStream with #on:

by Alexandre Bergel

> Put the readLimit at 0 make sense for a WriteStream ( with witch > your not supposed to read ) but when you create a ReadWriteStream on > a collection you would be able to read what is already in the > collection, no? > I wonder why #on: has not been overriden in the instance side of > ReadWriteStream ? > Maybe it's not a good idea to create a ReadWriteStream with a > collection that already includes elements ? It looks like on: must be overridden in ReadWriteStream. With ReadStream I have: (ReadStream on: (1 to: 20)) next => 1 (ReadStream on: (1 to: 20)) next; next => 2 However, with ReadWriteStream, nil is returned, for the very problem you mentioned: (ReadWriteStream on: (1 to: 20)) next => nil If I cut and paste PositionnableStream>>on: in ReadWriteStream, then I have the behavior I expected: (ReadWriteStream on: (1 to: 20)) next => 1 (ReadWriteStream on: (1 to: 20)) next; next => 2 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 30, 2009

Re: [Pharo-project] [ANN] Fix to issue 825

by Hernan Wilkinson

I agree with you Marcus, I think the driver should be the future, not the past, and more OO is definitely better. It is clear now that hardware is not the problem but the cost of maintaining software... On Tue, Jun 30, 2009 at 6:54 AM, Marcus Denker <denker(a)acm.org> wrote: > > On 30.06.2009, at 11:44, Douglas Brebner wrote: > > > Marcus Denker wrote: > >> I personally think that with today's resources (my laptop has 4GB of > >> Ram, not 256Kb), we should rethink some of the design-desicions taken > >> 30 years ago. But many people are violently against this, fighting a > >> battle by citing "embedded systems". If one manages to convince them > >> that "embedded" these days does not equal "small", they mumble about > >> "smart dust" and obscure things just to be able to fight for hacks > >> not needed these days... > >> > >> Exploring new ways with the resources we have today does not mean > >> that everything needs to live in the image. It means that one can > >> affort to invest resources into very general, reusable solution to > >> problems like this. > > > > Didn't Tim change CompiledMethods so they referred to their source > > using > > a pointer so the source could be stored anywhere? > > > > Yes, Tim did some changes (in 1998) to make compiledMethods normal > objects > that have a ByteArray for the bytecode and a normal instvar for the > pointer to > the source. IMHO the way to go, but it was never added to squeak... > mostly because > people feared the overhead (there are 40.000 methods, so adding > another 40.000 is > indeed noticable, as we have seen in 3.9 with the MethodProperties...). > > I personally like this change, as it makes the implementation higher- > level and more > OO, which I think is a good thing. I personally think that "more OO" > is better than > "more compact", considering that a laptop these days has 4GB (this is > GIGABYTES) of RAM. > I always wonder how Smaltalk would look like if it was disgned with > the same philosophy > in 1976 that people apply today. Using the "but it costs memory" > philosphy that everyone > favors today, Smalltalk would never have been done in 1976 at all. > > There is another patch floating around that allows larger sources/ > changes without > changing the mechanism too much. > > >> One interesting aspect of the source/changes "outside the image" is > >> that this problem of data that is not used often and thus can live on > >> disk vs. memory is a general one. Hacking it into the system just for > >> the sources is just that: a hack. Providing a general, scalable way > >> to let objects live on disk that are not needed is much better, as > >> everyone can than use it. The system can use it for other resources > >> (fonts, images...). Programmers can use it to keep their domain data > >> on disk automatically. > > > > > > You mean something like LOOM? I would love to have that :) > > > Yes! :-) > > Marcus > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 30, 2009