June 2015 - Pharo-dev - lists.pharo.org

Does anybody ever used compareToClipboard: ?

by stepharo

Does anybody ever used compareToClipboard: ? Because we are thinking to remove it.

June 9, 2015

Re: [Pharo-dev] Comments in STON

by stepharo

Le 9/6/15 20:06, stepharo a Ã©crit : > I will update the STON chapter :) Done :) > > > Le 8/6/15 23:39, Sven Van Caekenberghe a Ã©crit : >> I would do it like this: use a wrapping stream to skip comments. >> >> === >> Name: STON-Core-SvenVanCaekenberghe.59 >> Author: SvenVanCaekenberghe >> Time: 8 June 2015, 11:34:32.886167 pm >> UUID: 7ab942b5-9d1a-44c3-9d58-da29feb72380 >> Ancestors: STON-Core-SvenVanCaekenberghe.58 >> >> Add experimental STONCStyleCommentsSkipStream and tests >> === >> Name: STON-Tests-SvenVanCaekenberghe.54 >> Author: SvenVanCaekenberghe >> Time: 8 June 2015, 11:34:52.918771 pm >> UUID: 3dcb2c9c-6efe-4d62-bf36-3bbe91f09d08 >> Ancestors: STON-Tests-SvenVanCaekenberghe.53 >> >> Add experimental STONCStyleCommentsSkipStream and tests >> === >> >> Then you can do as follows: >> >> STON fromStream: (STONCStyleCommentsSkipStream on: 'Point[/* this is >> X*/ 1, /* this is Y*/ 2] // Nice huh ?' readStream). >> >> => 1@2 >> >> STON fromStream: (STONCStyleCommentsSkipStream on: '// Here is how >> you create a point: >> Point[ >> // this is X >> 1, >> // this is Y >> 2 ] >> // Nice huh ?' readStream). >> >> => 1@2 >> >> This helper class would be useable in other contexts too (like NeoJSON). >> >> The advantage is that it does not change the STON (or JSON) syntax >> itself, it just add some functionality for those who want it. >> >> What do you think ? >> >> Sven >> >> PS: this probably needs some more testing >> >>> On 08 Jun 2015, at 17:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> On 08 Jun 2015, at 17:03, Damien Cassou <damien.cassou(a)inria.fr> >>>> wrote: >>>> >>>> >>>> Sven Van Caekenberghe <sven(a)stfx.eu> writes: >>>> >>>>> I am not so sure we should add that. >>>>> >>>>> The JSON spec explicitly does not allow comments because of fear >>>>> of abuse (that the comments would be used to add semantic meaning >>>>> outside the spec). >>>> >>>> really? That's surprising. Comments in configuration files are very >>>> important. Even more when the configuration files are templates for >>>> new >>>> users. >>> I know some people are using STON in ways that I did not originally >>> anticipate, that is of course cool, but writing configuration files >>> was not the original goal. STON is a version of JSON that is closer >>> to our object model. >>> >>> Like I said, I will think about it. >>> >>>> -- >>>> Damien Cassou >>>> http://damiencassou.seasidehosting.st >>>> >>>> "Success is the ability to go from one failure to another without >>>> losing enthusiasm." --Winston Churchill >> >> > > >

June 9, 2015

Re: [Pharo-dev] Comments in STON

by stepharo

I will update the STON chapter :) Le 8/6/15 23:39, Sven Van Caekenberghe a Ã©crit : > I would do it like this: use a wrapping stream to skip comments. > > === > Name: STON-Core-SvenVanCaekenberghe.59 > Author: SvenVanCaekenberghe > Time: 8 June 2015, 11:34:32.886167 pm > UUID: 7ab942b5-9d1a-44c3-9d58-da29feb72380 > Ancestors: STON-Core-SvenVanCaekenberghe.58 > > Add experimental STONCStyleCommentsSkipStream and tests > === > Name: STON-Tests-SvenVanCaekenberghe.54 > Author: SvenVanCaekenberghe > Time: 8 June 2015, 11:34:52.918771 pm > UUID: 3dcb2c9c-6efe-4d62-bf36-3bbe91f09d08 > Ancestors: STON-Tests-SvenVanCaekenberghe.53 > > Add experimental STONCStyleCommentsSkipStream and tests > === > > Then you can do as follows: > > STON fromStream: (STONCStyleCommentsSkipStream on: 'Point[/* this is X*/ 1, /* this is Y*/ 2] // Nice huh ?' readStream). > > => 1@2 > > STON fromStream: (STONCStyleCommentsSkipStream on: '// Here is how you create a point: > Point[ > // this is X > 1, > // this is Y > 2 ] > // Nice huh ?' readStream). > > => 1@2 > > This helper class would be useable in other contexts too (like NeoJSON). > > The advantage is that it does not change the STON (or JSON) syntax itself, it just add some functionality for those who want it. > > What do you think ? > > Sven > > PS: this probably needs some more testing > >> On 08 Jun 2015, at 17:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> On 08 Jun 2015, at 17:03, Damien Cassou <damien.cassou(a)inria.fr> wrote: >>> >>> >>> Sven Van Caekenberghe <sven(a)stfx.eu> writes: >>> >>>> I am not so sure we should add that. >>>> >>>> The JSON spec explicitly does not allow comments because of fear of abuse (that the comments would be used to add semantic meaning outside the spec). >>> >>> really? That's surprising. Comments in configuration files are very >>> important. Even more when the configuration files are templates for new >>> users. >> I know some people are using STON in ways that I did not originally anticipate, that is of course cool, but writing configuration files was not the original goal. STON is a version of JSON that is closer to our object model. >> >> Like I said, I will think about it. >> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Success is the ability to go from one failure to another without >>> losing enthusiasm." --Winston Churchill > >

June 9, 2015

Re: [Pharo-dev] Comments in STON

by stepharo

so ugly! Le 8/6/15 17:27, Guillermo Polito a Ã©crit : > If not we could maybe write a yaml parser :) > > http://yaml.org/ > > It has no brackets, it is also hierarchical and it supports comments. > > El lun., 8 de jun. de 2015 a la(s) 5:16 p. m., Sven Van Caekenberghe > <sven(a)stfx.eu <mailto:sven@stfx.eu>> escribiÃ³: > > > > On 08 Jun 2015, at 17:03, Damien Cassou <damien.cassou(a)inria.fr > <mailto:damien.cassou@inria.fr>> wrote: > > > > > > Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> writes: > > > >> I am not so sure we should add that. > >> > >> The JSON spec explicitly does not allow comments because of > fear of abuse (that the comments would be used to add semantic > meaning outside the spec). > > > > > > really? That's surprising. Comments in configuration files are very > > important. Even more when the configuration files are templates > for new > > users. > > I know some people are using STON in ways that I did not > originally anticipate, that is of course cool, but writing > configuration files was not the original goal. STON is a version > of JSON that is closer to our object model. > > Like I said, I will think about it. > > > -- > > Damien Cassou > > http://damiencassou.seasidehosting.st > > > > "Success is the ability to go from one failure to another without > > losing enthusiasm." --Winston Churchill > > > >

June 9, 2015

SDL and windows.

by stepharo

(sending to you, since i don't have a email of the guy who asked me about it) So, in short the problem was: on Windows, SDL was generating text input events twice. As i predicted, the bug was interference between old-style event handling and SDL event handling, basically forcing SDL to process same event twice, that then turns into twice as much text input events on image side. Once i changed that, it no longer produces same events twice: if(ioCheckForEventsHooks) { /* HACK for SDL 2 */ ioCheckForEventsHooks(); } else { while(PeekMessage(&msg,NULL,0,0,PM_NOREMOVE)) { GetMessage(&msg,NULL,0,0); # ifndef NO_PLUGIN_SUPPORT if (msg.hwnd == NULL) pluginHandleEvent(&msg); # endif TranslateMessage(&msg); DispatchMessage(&msg); } } Now this code works in following way: - if SDL is not used, the VM will behave in 'legacy' mode. - but once event hook is installed, VM then places all responsibility on external event handler (SDL in our case) and does not processes any events by itself anymore. That actually what i predicted before: that we will be unable to support legacy event handling alongside SDL without interfering with each other, e.g. we can have one or another, but not both. So far, i will keep this code, since i obviously need to finish image conversion to work well with SDL, before i can completely throw away legacy event handling in VM. -- Best regards,

June 9, 2015

Re: [Pharo-dev] Getting a user input string using Morphs

by Peter UhnÃ¡k

If you don't need very specific control over the visuals of the UI I would highly recommend using Spec instead of Morphic. As for search, you can do something like ~~~~~~~~~~~~~~~~~~~ arr := #('Pharo' 'Squeak' 'VisualWorks'). c := EntryCompletion new dataSourceBlock: [ :currText | arr ]; filterBlock: [:currApplicant :currText | currApplicant includesSubstring: currText ]. m := TextInputFieldModel new. m entryCompletion: c. m openWithSpec ~~~~~~~~~~~~~~~~~~~ If you can describe in greater detail what exactly are you trying to achieve perhaps I would be able to give better hints. Cheers, Peter On Tue, Jun 9, 2015 at 5:46 PM, Jigyasa Grover <grover.jigyasa1(a)gmail.com> wrote: > Hi Max :) > > The alternative works the way I want, but it doesn't integrate well with > the > UI I have started to make with the help of Morphs. > > PS- Can I use /UIManager/ 'stuff' to make the entire GUI for my application > ? > > Regards > > > > -- > View this message in context: > http://forum.world.st/Getting-a-user-input-string-using-Morphs-tp4831122p48… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

June 9, 2015

Re: [Pharo-dev] Getting a user input string using Morphs

by Jigyasa Grover

Hi Peter I was planning to build something like this: <http://forum.world.st/file/n4831232/04.png> -- View this message in context: http://forum.world.st/Getting-a-user-input-string-using-Morphs-tp4831122p48… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 9, 2015

Re: [Pharo-dev] Testers needed! Re: Athens BitBlt bug?

by Igor Stasenko

On 13 May 2015 at 23:22, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-05-08 22:28 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > >> >> >> On 8 May 2015 at 22:20, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> >>> >>> 2015-05-08 21:42 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >>> >>>> >>>> >>>> On 8 May 2015 at 21:32, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On 8 May 2015 at 00:43, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>>> >>>>>> >>>>>> Some testers needed! >>>>>> >>>>>> I can not reproduce the BitBlt bug and I would like to get this >>>>>> right, so that surface pattern >>>>>> paints use the correct form dimension. >>>>>> >>>>>> Be sure, my fried, the bug is there, sitting in VM. >>>>> Bitblt implementation prereads a pixel from bitmap *before* checking >>>>> the loop bounds, meaning that it reads at least a single byte beyond the >>>>> actual contents of the bitmap. >>>>> It is not harmful in cases when bitmap is allocated in object memory >>>>> since VM memory design actually guarantees, that there are at least certain >>>>> amount of bytes in form of breathing space always available, so reading >>>>> single word past any allocated object is not hurts.. >>>>> But not in case, when bitmap residing in external heap.. because >>>>> reading beyond allocated space might cause segmentation fault.. and it was, >>>>> until i figured what was causing it and where the bug is. >>>>> >>>> >>> This mean it can happen every time we read form data from a surface >>> plugin - it is not only an issue for athens/cairo. >>> >>> Right, this is not cairo-only issue.. It just manifested itself when i >> was started using external surfaces allocated by cairo with bitblt. >> Which was causing occasional, irregular crashes time to time and i was >> quite lucky finding the cause of it. >> > > > Any chance you remember what triggers this error? What code did you use, > simple drawings or more advanced > use of athens. Image patterns, gradient patterns. > Or at least, what platform mac/win/linux? > > I tried different vm/image versions but only on windows so far. > > There were some changes on some bitblt functions, maybe the bug does not > exist anymore? > > the easiest way to reproduce it would be: - allocate a new surface of such dimensions, that its buffer size will be aligned with 4k page boundary (a smallest one would be 1x1024, or 1024x1, since one pixel is 4 bytes) - try to blit this surface with bitblt - crash (sure it happens not always, since often there could be another memory page allocated for other purposes with read access granted, but if you continuously do that, you will inevitable face the crash) > > nicolai > > >> >> >>> I will take a look at bitblt implementation. >>> >>> Thank you ! >>> >>> >>>> >>>>> >>>> The workaround, that i introduced was simply to tell Cairo to allocate >>>> surface 1 row taller and then use smaller height in bitblt operations, so >>>> it can never use the last row.. >>>> that, of course, going in conflict of using cairo for a patterns to >>>> fill things with bitmaps, which relying on surface's dimensions and using >>>> all its pixels.. >>>> :( >>>> >>>> hmm.. >>>> >>>>> >>>>> >>>>>> Prefered test setup: >>>>>> a (fresh) pharo image >>>>>> load bleeding edge from Bloc (because with bloc the whole (morphic) >>>>>> world is drawn with athens). >>>>>> change to watery theme ( because it makes some heavy use of form >>>>>> fills) >>>>>> verify that vertical scrollbars have this artifact (blank lines). >>>>>> load the attached code (this code reverts igors change for the 1 >>>>>> pixel extra height. >>>>>> >>>>>> please report back >>>>>> what platform windows/linux/mac 32/64 bit >>>>>> what pharo vm and image version. >>>>>> >>>>>> For me >>>>>> Windows 7 32 bit >>>>>> Win32 built on Apr 9 2015 21:05:04 Compiler: 4.6.2 >>>>>> Latest update: #50039 >>>>>> >>>>>> -> no segfault >>>>>> >>>>>> thanks in advance >>>>>> >>>>>> >>>>>> 2015-03-13 21:22 GMT+01:00 stepharo <stepharo(a)free.fr>: >>>>>> >>>>>>> I do not know. May be igor is reading this mailing-list but I doubt. >>>>>>> >>>>>>> >>>>>>> 2015-01-27 21:46 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >>>>>>> >>>>>>> Anyone knows what this BitBlt bug is or was? >>>>>>>> 12818 <https://pharo.fogbugz.com/default.asp?12818> Last row >>>>>>>> missing >>>>>>>> 13236 <https://pharo.fogbugz.com/default.asp?13236> Fix 1 extra >>>>>>>> height for Cairo surface >>>>>>>> >>>>>>>> Because with the fix in 13236, it is not (easily) possible to make >>>>>>>> a repeating (vertical) pattern paint with 1 pixel height: >>>>>>>> 14813 <https://pharo.fogbugz.com/default.asp?14813> Wrong size >>>>>>>> for Athens surface pattern paint from a Form >>>>>>>> >>>>>>>> >>>>>>>> nicolai >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> BUMP >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

June 9, 2015

Re: [Pharo-dev] Getting a user input string using Morphs

by Jigyasa Grover

Hi Max :) The alternative works the way I want, but it doesn't integrate well with the UI I have started to make with the help of Morphs. PS- Can I use /UIManager/ 'stuff' to make the entire GUI for my application ? Regards -- View this message in context: http://forum.world.st/Getting-a-user-input-string-using-Morphs-tp4831122p48… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 9, 2015

Re: [Pharo-dev] Refactoring File Package

by Sven Van Caekenberghe

Here is a first step in making the Zinc character encoding package lighter: === Name: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.38 Author: SvenVanCaekenberghe Time: 9 June 2015, 5:21:51.278641 pm UUID: 8b4b6a04-d2a2-4fec-97fe-6faf498bc54b Ancestors: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.37 Experimental change: introduction of ZnSimplifiedByteEncoder as a low memory variant of the full featured ZnByteEncoder, supporting only latin1 (iso-8859-1) and ascii. Move ASCII handling from ZnNullEncoder to ZnSimplifiedByteEncoder making it strict by default. Needs ZnSimplifiedByteEncoder initialize. ZnByteEncoder initialize. === Of course, now we have to decide how to really split the package, which parts to keep in the low level version, and which to move to the extended version. The tests might need splitting too. Sven > On 05 Jun 2015, at 19:35, stepharo <stepharo(a)free.fr> wrote: > > Yes sven but with guille we are working on a really small kernel. So we can duplicate just the classes we need but I would prefer not > but we can do it. The size is important for us because it takes time to bootstrap. > > Stef > > Le 5/6/15 19:06, Sven Van Caekenberghe a Ã©crit : >>> On 05 Jun 2015, at 18:43, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> >>> The only encoder that makes a bit of noise to me is the ZnByteEncoder that contains a lot of mapping tables for mostly unused encodings >> 67 encoding specifications, each a 128 array. The method constant is shared when used. >> In the beginning there were only a couple, one day I added many more, some people need them. >> For me, the cost is reasonable. >> >>> (plus methods with metadata to recreate them)... >> That is just two method (which is pretty cool, I love spec based programming). >> >>> El vie., 5 de jun. de 2015 a la(s) 6:30 p. m., Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: >>> >>>> On 05 Jun 2015, at 18:20, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Sven >>>> >>>> we were talking about splitting your package into two parts :) >>>> Would you be ok to get the basic encoders in a separate package? >>> Zinc-Character-Encoding is already a separate package, it depends on nothing. >>> Zinc-Resource-Meta is next up (containing URL and Mime-Type). >>> Both are completely independent of any HTTP stuff. >>> All this is by design. >>> >>> You probably mean that you want a separate config ? Right now they are just a groups. >>> >>>> We were also thinking that NullEncoder could be called AsciiEncoder? >>> Maybe, maybe not, let me think about that a bit. >>> >>>> Stef >>>> >>>>>> On 05 Jun 2015, at 18:09, Damien Cassou <damien.cassou(a)inria.fr> wrote: >>>>>> >>>>>> >>>>>> Guillermo Polito <guillermopolito(a)gmail.com> writes: >>>>>> >>>>>>> Well, I made a cleaner implementation at the side with >>>>>>> >>>>>>> - a simple File object that is a sequential File as we all know >>>>>>> - a binary File stream on top of it that is composable with Zn encoders and >>>>>>> other decorators >>>>>>> - a new interface to access Stdio streams >>>>>> that's really good news Guillermo. >>>>> Yes it is (need time to look at this in detail) >>>>> >>>>>> Is it ok to make File reading depend >>>>>> on Zinc? This sounds strange. Wouldn't that make bootstrapping harder? >>>>> It does not depend on the HTTP part, but on the Encoding part below it, so that should be OK. >>>>> >>>>>> -- >>>>>> Damien Cassou >>>>>> http://damiencassou.seasidehosting.st >>>>>> >>>>>> "Success is the ability to go from one failure to another without >>>>>> losing enthusiasm." --Winston Churchill >>>>>> >>>>> >>>> >>> >> >> > >

June 9, 2015