- Pharo-users - lists.pharo.org

Re: [Pharo-users] Laser Game

by Yuriy Tymchuk

Hi, yes it can. This is where your adventure begins :) Also I think that I may be easier to follow the tutorial step by step with Pharo. Then you'll solve problems just when they appear and not end up with a tons of unknown stuff. Uko On 2 Ð²ÐµÑ. 2013, at 15:02, ÐÐ°ÑÐºÑÑÐ½ Ð ÑÐ·ÑÐ½ <mrizun(a)gmail.com> wrote: > As was suggested above I tried to load Laser Game on Pharo 2.0 and it didn't work. > Can this problem be solved? > > > 2013/8/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Aug 16, 2013, at 11:11 AM, ÐÐ°ÑÐºÑÑÐ½ Ð ÑÐ·ÑÐ½ <mrizun(a)gmail.com> wrote: > >> Hi, everyone! >> I have been working on a tutorial 'how to make a game using smalltalk' and developed this game ( Laser Game ) on Squeak, as it is an example of development on Squeak. I'm learning, so it's a great experience for me. Laser Game is my first game and it's not complicated, but for me it took long time to make. >> Links: >> 1. http://squeak.preeminent.org/tut2007/html/ - website of tutorial >> 2. http://smalltalkhub.com/#!/~MarkRizun/LaserGame/source - Laser Game >> Comments are welcome:) > > I thought that you were doing it on Pharo. > It would be good to have it on pharo and to know what are the changes at the morphic level. >> Mark >> >> > >

Sept. 2, 2013

Re: [Pharo-users] Laser Game

by ÐÐ°ÑÐºÑÑÐ½ Ð ÑÐ·ÑÐ½

As was suggested above I tried to load Laser Game on Pharo 2.0 and it didn't work. Can this problem be solved? 2013/8/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Aug 16, 2013, at 11:11 AM, ÐÐ°ÑÐºÑÑÐ½ Ð ÑÐ·ÑÐ½ <mrizun(a)gmail.com> wrote: > > Hi, everyone! > I have been working on a tutorial 'how to make a game using smalltalk' and > developed this game ( Laser Game ) on Squeak, as it is an example of > development on Squeak. I'm learning, so it's a great experience for me. > Laser Game is my first game and it's not complicated, but for me it took > long time to make. > Links: > 1. http://squeak.preeminent.org/tut2007/html/ - website of tutorial > 2. http://smalltalkhub.com/#!/~MarkRizun/LaserGame/source - Laser Game > Comments are welcome:) > > > I thought that you were doing it on Pharo. > It would be good to have it on pharo and to know what are the changes at > the morphic level. > > Mark > > > >

Sept. 2, 2013

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

by Sven Van Caekenberghe

On 02 Sep 2013, at 10:34, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Aug 31, 2013, at 3:30 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 31 Aug 2013, at 13:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> Sabine >>> what we could do is to propose a "subclass of UUID" and to group several UUID generators. >>> Like that with a couple of classes, we could get a better eco system where people can pick the one they want. >>> >>> stef >> >> I just made my own, called NeoUUIDGenerator, http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe/Neo/packages/Neo-UUID >> >> @Sabine >> >> IMHO what I think a local counter does not, is give you uniques over different machines, images, instances - that is why there is also the concept of node identification. >> >> In my implementation I combine the millisecond clock, a small random number, a counter and a node id. The node id is based on several elements, it should be different when running multiple images. >> >> This is a hack, not something that I can prove mathematically. But it can't be worse than pure random. I think the speed is also acceptable: >> >> | generator | >> generator := NeoUUIDGenerator new. >> [ generator next ] bench. '408,000 per second.' >> >> | generator | >> generator := UUIDGenerator new. >> [ generator generateBytes: UUID nilUUID forVersion: 4 ] bench. '13,300 per second.' >> >> Sven > > So sorta like UUID type 3/5, but with a custom object identifier scheme, and no hashing? > Not sure it'd be fair to call that any kind of UUIDGenerator anymore, as the UUID standard and its encompassing types is a pretty well-defined ;) Yes, it is a hack, mixing type 3/5 elements while pretending to be type 4 ;-) > IIRC, the reason those went out of flavor in favor of type 4, is the fact they do potentially identify the source computer from which they were created, and thus a purely random approach was considered better. (as long as it is just that, which, as this thread illustrates, is another matter) Somehow, I don't feel like just random data would do. Maybe the chance for repetition is low, but it is not zero across instances, images and machines, and it depends on the quality of a random generator that is hard to control. I have this feeling that adding a counter, the time and a node identification is better. But this is totally unscientific. > Cheers, > Henry

Sept. 2, 2013

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

by Henrik Johansen

On Aug 31, 2013, at 3:30 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 31 Aug 2013, at 13:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Sabine >> what we could do is to propose a "subclass of UUID" and to group several UUID generators. >> Like that with a couple of classes, we could get a better eco system where people can pick the one they want. >> >> stef > > I just made my own, called NeoUUIDGenerator, http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe/Neo/packages/Neo-UUID > > @Sabine > > IMHO what I think a local counter does not, is give you uniques over different machines, images, instances - that is why there is also the concept of node identification. > > In my implementation I combine the millisecond clock, a small random number, a counter and a node id. The node id is based on several elements, it should be different when running multiple images. > > This is a hack, not something that I can prove mathematically. But it can't be worse than pure random. I think the speed is also acceptable: > > | generator | > generator := NeoUUIDGenerator new. > [ generator next ] bench. '408,000 per second.' > > | generator | > generator := UUIDGenerator new. > [ generator generateBytes: UUID nilUUID forVersion: 4 ] bench. '13,300 per second.' > > Sven So sorta like UUID type 3/5, but with a custom object identifier scheme, and no hashing? Not sure it'd be fair to call that any kind of UUIDGenerator anymore, as the UUID standard and its encompassing types is a pretty well-defined ;) IIRC, the reason those went out of flavor in favor of type 4, is the fact they do potentially identify the source computer from which they were created, and thus a purely random approach was considered better. (as long as it is just that, which, as this thread illustrates, is another matter) Cheers, Henry

Sept. 2, 2013

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

by Henrik Johansen

On Aug 30, 2013, at 4:35 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 29 Aug 2013, at 16:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> hi >>> >>> well... I've never been happy on using the UUID generator for my keys, but is the fastest option I found. >>> There are, of course, alternatives: >>> >>> 1) Using your own number generator (sequential, or whatever). Problem with that is that is image based, then you need a persistence strategy... then you are slow. >>> 2) then you can use your own procedure in mongo... with same problem than (1) >>> 3) you could use timestamp. but TimeStamps are slow :( >>> >>> anyway... I open to ideas :) >>> >>> in the mean time, you can check if your UUID generator is using the primitive or not. In you are not, you have more possibilities of having a collision. >> >> Yes, the Smalltalk code (type 4 UUID) is just a random number that is computed in a complex way. >> >> What does the primitive actually do ? Is it different ? > > the primitive uses the clock ticks to produce an UUID... you shouldn't have repeated numbers that way... but well, it depends on the platform implementation also. Wait, which primitive is this? UUID > primMakeUUID? That code calls libUUID, which (as long as it doesn't crash :P) fetches from dev/urandom (or the windows equivalent RtlGenRandom), there shouldn't ever be a problem getting duplicate results unless those system-provided resources are bugged, in which case your entire system is borked. The fallback code using UUIDGenerator default admittedly has a weak PRNG, and is dog slow: gen := UUIDGenerator new. [gen generateFieldsVersion4] bench '12,900 per second.' [ UUID new ] bench '3,610,000 per second.' "Primitive working, btw" but that hardly means you should run into duplicate sequential UUID'sâ¦ The *only* way sequentially equal UUID's could arise, is if one uses UUIDGenerator directly, and creates a new instance each time, which does indeed run the risk of returning values derived from the same Time initialization , but that should *never* be doneâ¦ Cheers, Henry

Sept. 2, 2013

Re: [Pharo-users] Group and member with Voyage

by Norbert Hartl

Am 31.08.2013 um 02:18 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > I think that the question could be rephrased as: > > How to map a collection with elements of different classes? > > Am I asking for too much? > No, but this isn't a trivial problem. For your specific case it is probably not implemented. I still didn't find the time to look into voyage but I think it has basically two modes: Either you use it plain (no magritte) and types are inferred from the object. Voyage then adds the information about the class in the json being serialized. If you use magritte then it can take the information from the description. So your case is a mix of the two. You can take basic information from the description but if it comes to inheritance you still need to add the class information in the json to be able to deserialize properly. The sad story about this is that relationships aren't perfect in magritte and nobody finds time to work out a proper solution. For your case and other problems there needs to be a fix and having separate descriptions for homogenous and heterogenous collections might be an approach that solves a few things. Norbert > > Esteban A. Maringolo > > > 2013/8/30 Esteban A. Maringolo <emaringolo(a)gmail.com>: >> More or less, I have this working. >> >> In the Group class I have a description named: >> descriptionMembers >> <mongoDescription> >> ^VOMongoToManyDescription new >> attributeName: 'members'; >> accessor: #members; >> kind: Member; >> beLazy; >> yourself >> >> >> And in the Member class I have >> descriptionGroups >> <mongoDescription> >> ^VOMongoToManyDescription new >> attributeName: 'groups'; >> accessor: #groups; >> kind: Group; >> beLazy; >> yourself >> >> >> >> But what if Member is an abstract class and the elements can be any of >> SingleMember or ComplexMember?, each one is stored in a separate >> collection in Mongo. >> >> If I do specify #kind: Member in my #descriptionMembers it won't work. >> >> Any ideas? >> >> Regards, >> >> >> Esteban A. Maringolo >> >> >> 2013/8/30 Esteban A. Maringolo <emaringolo(a)gmail.com>: >>> 2013/8/30 James Foster <Smalltalk(a)jgfoster.net>: >>>> It seems that I mistook the question for something easy enough for me to answer! Unfortunately, I don't have any knowledge of Voyage+MongoDB so can't really give the proper answer. >>> >>> Thanks anyway, it is a problem you'll never find in GemStone/S ;-) >

Sept. 1, 2013

Re: [Pharo-users] Postmark email library

by StÃ©phane Ducasse

> It's work fine! Excellent. > Tested on clean image of pharo 2.0. > > Thank you! Now you have to read the metacello chapter ;D and have success coding in Pharo. And if you see glitches or space for improvements in Postmark, please do not hesitate. > > -- > View this message in context: http://forum.world.st/Postmark-email-library-tp4254680p4705969.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Aug. 31, 2013

Re: [Pharo-users] Postmark email library

by vmusulainen

It's work fine! Tested on clean image of pharo 2.0. Thank you! -- View this message in context: http://forum.world.st/Postmark-email-library-tp4254680p4705969.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 31, 2013

Re: [Pharo-users] Voyage: image freeze/VOMongoError: Lazy reference not found

by Esteban A. Maringolo

2013/8/31 Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com>: > Hi Esteban, > > til now, it did not come back to me. > Can you reproduce it with a fresh image? The image freezed, but fortunately with a LOT of patience I was able to type a character every once in a while. So I could write an smalltalk expression that after being evaluated opened a debugger and caused the image to get responsive again. The expression was a last resort in order to "cause" another error that could give me the control back. VOLazyProxy allInstances do: [:each | each become: String new ] It worked. > Btw I am saving my image now each hour or so... I'm not used to do it, I trust in the changes file, the problem is that I saved the image with the offending proxy. The problem was a modification of a document in a collection. I did a mongo upsert that changed it, and apparently Voyage didn't know how to handle it. Regards!

Aug. 31, 2013

Re: [Pharo-users] Voyage: image freeze/VOMongoError: Lazy reference not found

by Sabine KnÃ¶fel

Hi Esteban, til now, it did not come back to me. Can you reproduce it with a fresh image? Btw I am saving my image now each hour or so... Sabine On Sat, Aug 31, 2013 at 5:46 PM, Esteban A. Maringolo [via Smalltalk] < ml-node+s1294792n4705953h38(a)n4.nabble.com> wrote: > I've been bitten by this too. > This is when the "image" concept get counterproductive if you didn't > commit all your code changes. :-/ > > Esteban A. Maringolo > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://forum.world.st/Voyage-image-freeze-VOMongoError-Lazy-reference-not-f… > To unsubscribe from Voyage: image freeze/VOMongoError: Lazy reference not > found, click here<http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML<http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/Voyage-image-freeze-VOMongoError-Lazy-reference-not-f… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 31, 2013