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

Re: [Pharo-dev] Random number generator bug?

by Ben Coman

On Windows 7, I tried two case and could not reproduce this. 1. Pharo-40611 C:\#Pharo\Pharo4.0\Pharo.exe NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014 NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014 Note the same VM as yours 2. Pharo-50554 C:\#Pharo\PharoSpur\Pharo.exe CoInterpreter VMMaker.oscog-eem.1630 uuid: 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 14 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid: 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 14 2016 https://github.com/estebanlm/pharo-vm.git Commit: 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #498 Could you try some other combinations of machine/VM/image? cheers -ben On Wed, Jun 29, 2016 at 12:15 PM, Benoit St-Jean via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstjean(a)yahoo.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Cc: > Date: Wed, 29 Jun 2016 04:13:57 +0000 (UTC) > Subject: Random number generator bug? > I'm having problems understanding why the Integer>>#atRandom sometimes return a number greater than the receiver. > > This problem only occurs when forking processes that generate random number using the above mentioned method. Obviously, all processes share the same RNG from the Collection class. > > Code below can reproduce (most of the time) the bug. > > | n | > n := 3172918. > 5 timesRepeat: [ [n timesRepeat: [ | alea | > alea := n atRandom. > (alea > n) ifTrue: [ self halt]]] forkAt: Processor userBackgroundPriority ]. > > I'm on Windows 10, Pharo4.0 Latest update: #40627. > > Pertinent System Reporter info below: > > Virtual Machine > --------------- > F:\Pharo4\Pharo4.0\Pharo.exe > NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014 > NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014 > https://github.com/pharo-project/pharo-vm.git Commit: 81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14858 > > Win32 built on Sep 25 2014 17:47:04 Compiler: 4.6.2 > VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: 81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14858 > NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014 > NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014 > > Loaded VM Modules > ----------------- > B2DPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > BitBltPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > FT2Plugin Freetype-Plugin-IgorStasenko.64 (e) > FilePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > FloatArrayPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > JPEGReadWriter2Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > Kernel32 > LargeIntegers v1.5 VMMaker.oscog-jeanbaptistearnaud.783 (i) > LocalePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > Matrix2x3Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > MiscPrimitivePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > NativeBoostPlugin NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 (i) > SecurityPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > ZipPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > > VM Built-in Modules > ------------------- > ADPCMCodecPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > AsynchFilePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > B2DPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > B3DAcceleratorPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > BMPReadWriterPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > BitBltPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > CroquetPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > DSAPrims VMMaker.oscog-jeanbaptistearnaud.783 (i) > DropPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > FFTPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > FilePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > FloatArrayPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > FloatMathPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > HostWindowPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > IA32ABI VMMaker.oscog-jeanbaptistearnaud.783 (i) > JPEGReadWriter2Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > JPEGReaderPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > JoystickTabletPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > Klatt VMMaker.oscog-jeanbaptistearnaud.783 (i) > LargeIntegers v1.5 VMMaker.oscog-jeanbaptistearnaud.783 (i) > LocalePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > MIDIPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > Matrix2x3Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > MiscPrimitivePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > Mpeg3Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > NativeBoostPlugin NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 (i) > RePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > SecurityPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > SerialPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > SocketPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > SoundCodecPrims VMMaker.oscog-jeanbaptistearnaud.783 (i) > SoundPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > StarSqueakPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > SurfacePlugin Sep 25 2014 (i) > UUIDPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > Win32OSProcessPlugin VMConstruction-Plugins-OSProcessPlugin.oscog-EstebanLorenzano.43 (i) > ZipPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) > > VM Configuration > ---------------- > F:\Pharo4\Pharo4.0\Pharo.ini > [Global] > DeferUpdate=1 > ShowConsole=0 > DynamicConsole=1 > ReduceCPUUsage=0 > ReduceCPUInBackground=0 > 3ButtonMouse=0 > 1ButtonMouse=0 > UseDirectSound=1 > PriorityBoost=0 > B3DXUsesOpenGL=0 > CaseSensitiveFileMode=0 > > Operating System/Hardware > ------------------------- > Win32 6.2 IX86 > > Hardware Details > ---------------- > Hardware information: > Manufacturer: Unknown > Model: Unknown > Number of processors: 4 > Page size: 4096 > > Memory Information (upon launch): > Physical Memory Size: 2097151 kbytes > Physical Memory Free: 2097151 kbytes > Page File Size: 4194303 kbytes > Page File Free: 4194303 kbytes > Virtual Memory Size: 2097024 kbytes > Virtual Memory Free: 2015568 kbytes > Memory Load: 45 percent > > Processor 0: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz > Identifier: Intel64 Family 6 Model 94 Stepping 3 > ~MHZ: 2712 > > Processor 1: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz > Identifier: Intel64 Family 6 Model 94 Stepping 3 > ~MHZ: 2712 > > Processor 2: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz > Identifier: Intel64 Family 6 Model 94 Stepping 3 > ~MHZ: 2712 > > Processor 3: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz > Identifier: Intel64 Family 6 Model 94 Stepping 3 > ~MHZ: 2712 > > Graphics Hardware Details > ------------------------- > Display Information: > Graphics adapter name: Intel(R) HD Graphics 530 > Primary monitor resolution: 1280 x 720 > > Device: ??? > Adapter String: Intel(R) HD Graphics 530 > Bios String: Intel Video BIOS > Chip Type: Intel(R) HD Graphics Family > DAC Type: Internal > Memory Size: 0x40000000 > > Driver Versions: > igdumdim64: > > > > > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) >

June 29, 2016

Re: [Pharo-dev] [squeak-dev] The .changes file should be bound to a single image

by Max Leske

> On 29 Jun 2016, at 02:06, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Tue, Jun 28, 2016 at 04:47:00PM -0500, Chris Muller wrote: >> >> On Tue, Jun 28, 2016 at 5:04 AM, Max Leske <maxleske(a)gmail.com> wrote: >>> Hi, >>> >>> Opening the same image twice works fine as long as no writes to the .changes file occur. When both images write to the .changes file however it will be broken for both because the offsets for the changes are wrong. This can lead to lost data and predominantly to invalid method source code, which is a pain with Monticello. >>> >>> I suggest that we implement a kind of lock mechanism to ensure that only one image (the first one opened) can write to the .changes file. >>> > > If the offsets are wrong in this scenario, it's a bug in the image. The > image is supposed to seek to the end of the changes file before writing > the next chunk. While this sounds horrible in theory, in practice it works > remarkably well, and I have been happily surprised at how reliable it > is after many years of using and abusing the feature. That is a very > good thing. > > Adding a lock to prevent the scenario would be bad, because it would > surely break a number of other legitimate use cases. > > >>> >>> I???ve opened an issue for Pharo here: https://pharo.fogbugz.com/f/cases/18635/The-changes-file-should-be-bound-to… >>> >> >> >> I have several applications which launch multiple copies of the same >> image for multicore processing. The images do their work, commit it >> to database, then exit themselves without saving. Its a great >> feature. Doing work is not the problem. Modifying source code is the problem. > > That is consistent with my experience. I remember expecting horrible > things to happen if I had two images sharing a changes file, but nothing > bad ever happened. It just works. > >> >> I know OSProcess, when combined with CommandShell, has a RemoteTask >> which allows efficient forking of the image (via Linux copy-on-write >> memory sharing) and so a solution like what happens in Windows is not >> really good. > > My assumption with RemoteTask was that someone doing complex or long-running > jobs would more or less know what they were doing, and would have the good > sense to stop writing to the changes file from a bunch of forked images. > But in actual practice, I have never seen a problem related to this. > It just works. > >> >> Instead of putting a pop-up in front of the user, perhaps one way to >> solve the problem would be to, upon image save, simply goes through >> all the changes since the last save and re-flushes them to the >> .changes file. >> >> That way, if someone does want to save the same image on top of >> themself, at least it would be whichever saved last "wins".... >> > > There must be a problem somewhere, otherwise Max would not be raising > the issue. So whatever combination of operating system and image is > having a problem, I would be inclined fix that. :) Thanks Dave! > > Windows cannot be a problem, because the operating system will not > permit you to open the changes file twice. The Unix/Linux systems that > I have used all work fine. > > Max, which operating system/VM/image are you using? Is this on a Mac? Mac OS X 10.11.5, Pharo 6 (60086) > > Dave > > I actually didnât open the issue for myself but because of a student who ran into this. Iâve been in the same situation before but Iâm an experienced user while students at the research group sometimes just spend a couple of weeks with Pharo and then such things are a real problem. Interestingly the issue is, as you already suggested, pretty hard to reproduce i.e., modifying arbitrary methods in both images did not show the symptoms I was looking for. Hereâs a reproducible case (at least on my machine): 1. create a new method in both images: foo ^ nil 2. Modify it in one image: foo "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum." ^ nil + 1 3. Modify it in the other image: foo ^ nil - 1 isEmpty ifTrue: [ "blah" nil ] In my case saving in step three produces a syntax error when the source is loaded from file again. I donât really have a clue as to what the underlying issue is, but I suspect it may have to do with comments and a particular situation in which the position is not being correctly updated before or after writing. I agree with Chris that locks may be problematic, it just seemed like the simplest obvious solution (although of course it gets complicated when an image crashes and doesnât clean up the lockâ¦). Cheers, Max >

June 29, 2016

Random number generator bug?

by Benoit St-Jean

I'm having problems understanding why the Integer>>#atRandom sometimes return a number greater than the receiver. This problem only occurs when forking processes that generate random number using the above mentioned method.Â Obviously, all processes share the same RNG from the Collection class. Code below can reproduce (most of the time) the bug. | n | n := 3172918. 5 timesRepeat: [ [n timesRepeat: [ | alea | Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â alea := n atRandom. Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (alea > n) ifTrue: [ self halt]]] forkAt: Processor userBackgroundPriority ]. I'm on Windows 10, Pharo4.0 Latest update: #40627. Pertinent System Reporter info below: Virtual Machine --------------- F:\Pharo4\Pharo4.0\Pharo.exe NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014 NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014 https://github.com/pharo-project/pharo-vm.git Commit: 81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14858 Win32 built on Sep 25 2014 17:47:04 Compiler: 4.6.2 VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: 81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14858 NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014 NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Sep 25 2014 Loaded VM Modules ----------------- B2DPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) BitBltPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) FT2Plugin Freetype-Plugin-IgorStasenko.64 (e) FilePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) FloatArrayPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) JPEGReadWriter2Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i) Kernel32 LargeIntegers v1.5 VMMaker.oscog-jeanbaptistearnaud.783 (i) LocalePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) Matrix2x3Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i) MiscPrimitivePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) NativeBoostPlugin NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 (i) SecurityPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) ZipPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) VM Built-in Modules ------------------- ADPCMCodecPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) AsynchFilePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) B2DPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) B3DAcceleratorPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) BMPReadWriterPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) BitBltPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) CroquetPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) DSAPrims VMMaker.oscog-jeanbaptistearnaud.783 (i) DropPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) FFTPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) FilePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) FloatArrayPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) FloatMathPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) HostWindowPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) IA32ABI VMMaker.oscog-jeanbaptistearnaud.783 (i) JPEGReadWriter2Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i) JPEGReaderPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) JoystickTabletPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) Klatt VMMaker.oscog-jeanbaptistearnaud.783 (i) LargeIntegers v1.5 VMMaker.oscog-jeanbaptistearnaud.783 (i) LocalePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) MIDIPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) Matrix2x3Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i) MiscPrimitivePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) Mpeg3Plugin VMMaker.oscog-jeanbaptistearnaud.783 (i) NativeBoostPlugin NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 (i) RePlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) SecurityPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) SerialPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) SocketPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) SoundCodecPrims VMMaker.oscog-jeanbaptistearnaud.783 (i) SoundPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) StarSqueakPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) SurfacePlugin Sep 25 2014 (i) UUIDPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) Win32OSProcessPlugin VMConstruction-Plugins-OSProcessPlugin.oscog-EstebanLorenzano.43 (i) ZipPlugin VMMaker.oscog-jeanbaptistearnaud.783 (i) VM Configuration ---------------- F:\Pharo4\Pharo4.0\Pharo.ini [Global] DeferUpdate=1 ShowConsole=0 DynamicConsole=1 ReduceCPUUsage=0 ReduceCPUInBackground=0 3ButtonMouse=0 1ButtonMouse=0 UseDirectSound=1 PriorityBoost=0 B3DXUsesOpenGL=0 CaseSensitiveFileMode=0 Operating System/Hardware ------------------------- Win32 6.2 IX86 Hardware Details ---------------- Hardware information: Â Â Â Manufacturer: Unknown Â Â Â Model: Unknown Â Â Â Number of processors: 4 Â Â Â Page size: 4096 Memory Information (upon launch): Â Â Â Physical Memory Size: 2097151 kbytes Â Â Â Physical Memory Free: 2097151 kbytes Â Â Â Page File Size: 4194303 kbytes Â Â Â Page File Free: 4194303 kbytes Â Â Â Virtual Memory Size: 2097024 kbytes Â Â Â Virtual Memory Free: 2015568 kbytes Â Â Â Memory Load: 45 percent Processor 0: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz Â Â Â Identifier: Intel64 Family 6 Model 94 Stepping 3 Â Â Â ~MHZ: 2712 Processor 1: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz Â Â Â Identifier: Intel64 Family 6 Model 94 Stepping 3 Â Â Â ~MHZ: 2712 Processor 2: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz Â Â Â Identifier: Intel64 Family 6 Model 94 Stepping 3 Â Â Â ~MHZ: 2712 Processor 3: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz Â Â Â Identifier: Intel64 Family 6 Model 94 Stepping 3 Â Â Â ~MHZ: 2712 Graphics Hardware Details ------------------------- Display Information: Â Â Â Graphics adapter name: Intel(R) HD Graphics 530 Â Â Â Primary monitor resolution: 1280 x 720 Device: ??? Â Â Â Adapter String: Intel(R) HD Graphics 530 Â Â Â Bios String: Intel Video BIOS Â Â Â Chip Type: Intel(R) HD Graphics Family Â Â Â DAC Type: Internal Â Â Â Memory Size: 0x40000000 Driver Versions: Â Â Â igdumdim64: Â ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein)

June 29, 2016

Re: [Pharo-dev] Having comments for pragma?

by Eliot Miranda

> On Jun 28, 2016, at 5:30 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi Eliot. > || Are you being serious or sarcastic? > I was sarcastics. Please don't kill me. I just too much hate java. I worked on it to much :)) > :) > 28 Ð¸ÑÐ½Ñ 2016 Ð³. 18:05 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Eliot Miranda" <eliot.miranda(a)gmail.com> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: >> >> >>> On Jun 28, 2016, at 8:17 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> Following this "bad idea" we should agree that smalltalk metaclass system is horrible and class should be just a language artifact >>> >> Are you being serious or sarcastic? >> >>> 28 Ð¸ÑÐ½Ñ 2016 Ð³. 11:45 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Jan Vrany" <jan.vrany(a)fit.cvut.cz> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: >>>> >>>> >>>>> On Mon, Jun 27, 2016 at 1:09 PM, Nicolas Passerini <npasserini(a)gmail.com> wrote: >>>>> >>>>> >>>>>> On Mon, Jun 27, 2016 at 1:44 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>>>>> >>>>>> 2016-06-27 13:28 GMT+02:00 Nicolas Passerini <npasserini(a)gmail.com>: >>>>>>> That is not quite true, annotations are (kind of) objects but you can not put behavior in them, just define attributes and optionally default values for those attributes. >>>>>> >>>>>> Ah, you are right. I remember many restrictions was applied to them which always forced me to hate Java :) >>>>> >>>>> Yep. >>>> >>>> Well, there's a reason why they're restricted. Note, that the restriction is on language level, not at runtime level. A annotation class >>>> with arbitrary code would pass JVM verification (or at least I can't see a rule that would reject such a class). >>>> >>>> When I implemented annotation support I was initially thinking the same - let's create an instance of CoolAnnotationClass when the code is accepted >>>> and then one can add arbitrary code to his CoolAnnotationClass. I quickly realized this is a (very) bad idea. Or, to be precise, it is a bad idea given the >>>> environment. So I'd be very careful.. >>>> >>>> Jan >>>> >>>> P.S.: As for "which always forced me to hate Java": I found myself a very enlightening to think carefully about why somebody else >>>> do things differently before I start to hate her/him. Besides, there's whole lot of things that Java guys got right...

June 29, 2016

Re: [Pharo-dev] Having comments for pragma?

by Denis Kudriashov

Hi Eliot. || Are you being serious or sarcastic? I was sarcastics. Please don't kill me. I just too much hate java. I worked on it to much :)) 28 Ð¸ÑÐ½Ñ 2016 Ð³. 18:05 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Eliot Miranda" <eliot.miranda(a)gmail.com> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > > > On Jun 28, 2016, at 8:17 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > Following this "bad idea" we should agree that smalltalk metaclass system > is horrible and class should be just a language artifact > > Are you being serious or sarcastic? > > 28 Ð¸ÑÐ½Ñ 2016 Ð³. 11:45 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Jan Vrany" <jan.vrany(a)fit.cvut.cz> > Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > >> >> >> On Mon, Jun 27, 2016 at 1:09 PM, Nicolas Passerini <npasserini(a)gmail.com> >> wrote: >> >> >> >> On Mon, Jun 27, 2016 at 1:44 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> >>> 2016-06-27 13:28 GMT+02:00 Nicolas Passerini <npasserini(a)gmail.com>: >>> >>>> That is not quite true, annotations are (kind of) objects but you can >>>> not put behavior in them, just define attributes and optionally default >>>> values for those attributes. >>> >>> >>> Ah, you are right. I remember many restrictions was applied to them >>> which always forced me to hate Java :) >>> >> >> Yep. >> >> >> Well, there's a reason why they're restricted. Note, that the restriction >> is on language level, not at runtime level. A annotation class >> with arbitrary code would pass JVM verification (or at least I can't see >> a rule that would reject such a class). >> >> When I implemented annotation support I was initially thinking the same - >> let's create an instance of CoolAnnotationClass when the code is accepted >> and then one can add arbitrary code to his CoolAnnotationClass. I quickly >> realized this is a (very) bad idea. Or, to be precise, it is a bad idea >> given the >> environment. So I'd be very careful.. >> >> Jan >> >> P.S.: As for "which always forced me to hate Java": I found myself a very >> enlightening to think carefully about why somebody else >> do things differently before I start to hate her/him. Besides, there's >> whole lot of things that Java guys got right... >> >> >>

June 29, 2016

Re: [Pharo-dev] [squeak-dev] The .changes file should be bound to a single image

by David T. Lewis

On Tue, Jun 28, 2016 at 04:47:00PM -0500, Chris Muller wrote: > > On Tue, Jun 28, 2016 at 5:04 AM, Max Leske <maxleske(a)gmail.com> wrote: > > Hi, > > > > Opening the same image twice works fine as long as no writes to the .changes file occur. When both images write to the .changes file however it will be broken for both because the offsets for the changes are wrong. This can lead to lost data and predominantly to invalid method source code, which is a pain with Monticello. > > > > I suggest that we implement a kind of lock mechanism to ensure that only one image (the first one opened) can write to the .changes file. > > If the offsets are wrong in this scenario, it's a bug in the image. The image is supposed to seek to the end of the changes file before writing the next chunk. While this sounds horrible in theory, in practice it works remarkably well, and I have been happily surprised at how reliable it is after many years of using and abusing the feature. That is a very good thing. Adding a lock to prevent the scenario would be bad, because it would surely break a number of other legitimate use cases. > > > > I???ve opened an issue for Pharo here: https://pharo.fogbugz.com/f/cases/18635/The-changes-file-should-be-bound-to… > > > > > I have several applications which launch multiple copies of the same > image for multicore processing. The images do their work, commit it > to database, then exit themselves without saving. Its a great > feature. That is consistent with my experience. I remember expecting horrible things to happen if I had two images sharing a changes file, but nothing bad ever happened. It just works. > > I know OSProcess, when combined with CommandShell, has a RemoteTask > which allows efficient forking of the image (via Linux copy-on-write > memory sharing) and so a solution like what happens in Windows is not > really good. My assumption with RemoteTask was that someone doing complex or long-running jobs would more or less know what they were doing, and would have the good sense to stop writing to the changes file from a bunch of forked images. But in actual practice, I have never seen a problem related to this. It just works. > > Instead of putting a pop-up in front of the user, perhaps one way to > solve the problem would be to, upon image save, simply goes through > all the changes since the last save and re-flushes them to the > .changes file. > > That way, if someone does want to save the same image on top of > themself, at least it would be whichever saved last "wins".... > There must be a problem somewhere, otherwise Max would not be raising the issue. So whatever combination of operating system and image is having a problem, I would be inclined fix that. Windows cannot be a problem, because the operating system will not permit you to open the changes file twice. The Unix/Linux systems that I have used all work fine. Max, which operating system/VM/image are you using? Is this on a Mac? Dave

June 29, 2016

Re: [Pharo-dev] [squeak-dev] The .changes file should be bound to a single image

by Chris Muller

I have several applications which launch multiple copies of the same image for multicore processing. The images do their work, commit it to database, then exit themselves without saving. Its a great feature. I know OSProcess, when combined with CommandShell, has a RemoteTask which allows efficient forking of the image (via Linux copy-on-write memory sharing) and so a solution like what happens in Windows is not really good. Instead of putting a pop-up in front of the user, perhaps one way to solve the problem would be to, upon image save, simply goes through all the changes since the last save and re-flushes them to the .changes file. That way, if someone does want to save the same image on top of themself, at least it would be whichever saved last "wins".... On Tue, Jun 28, 2016 at 5:04 AM, Max Leske <maxleske(a)gmail.com> wrote: > Hi, > > Opening the same image twice works fine as long as no writes to the .changes file occur. When both images write to the .changes file however it will be broken for both because the offsets for the changes are wrong. This can lead to lost data and predominantly to invalid method source code, which is a pain with Monticello. > > I suggest that we implement a kind of lock mechanism to ensure that only one image (the first one opened) can write to the .changes file. > > > Iâve opened an issue for Pharo here: https://pharo.fogbugz.com/f/cases/18635/The-changes-file-should-be-bound-to… > > > Cheers, > Max

June 28, 2016

Re: [Pharo-dev] Importing a GNU Smalltalk project into Pharo

by Dimitris Chloupis

Ah did not realize that it has an IDE, will give it a try, thanks On Tue, 28 Jun 2016 at 11:00, Holger Freyther <holger(a)freyther.de> wrote: > > > On 08 Jun 2016, at 13:40, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > Hi! > > > > I dont see many people who use a smalltalk that is not a smalltalk , the > same way a human is not an arm, wanting to come to pharo and locked in an > IDE and Enviroment. But then there are a tiny amount of them out there > anyway, judging from their mailing list that is barely alive. > > It really helped me to move from dominant languages (C, C++, python, ruby) > to Smalltalk without having to change everything at once. And to this date > being able to do git grep has its benefits when discovering code over > Nautilus (and speed of search is not the only one). > > > > > Gnu Smalltalk is like keeping the cherry and throwing away the cake. I > think its far more important to attrack the right kind of people who > believe or seek the smalltalk ideal. > > What is the cake? GNU Smalltalk is a real Smalltalk. thisContext, image > save/resume, tiny images, deployment on ARM, quick repl, graphical class > browsers, continuations when they were the cool thing, seaside, magritte, a > very approachable kernel/VM and good file/event/io integration. > > cheers > holger >

June 28, 2016

Re: [Pharo-dev] Percent-encoding problem

by Sven Van Caekenberghe

Bernard, I understand the issue, but this is not so easy to fix. I must start by saying that encoding a (part of) a URL with anything but UTF-8 is wrong (how would the receiver know, unless you have a mutual external agreement). So I guess you must be using some old web service. The solution is to make your own ZnUrl subclass and overwrite #encodePath:on: Then you just instanciate your subclass from elementary parts (no encoding) and pass it to ZnClient>>#url: as an object, not a string. Mind you, I haven't tried this yet. Sven > On 28 Jun 2016, at 20:26, Bernhard Pieber <bernhard(a)pieber.com> wrote: > > I have a web service where I have to use a URL with percent-encoded (URL encoded) special characters â German Umlauts â but not using UTF8 but ISO-8859-1. I have been given the following table for the âcorrectâ encodings: http://www.degraeve.com/reference/urlencoding.php > > I found out that I can use the following to get the encoding I need (%FC): > ZnPercentEncoder new > characterEncoder: (ZnCharacterEncoder newForEncoding: 'iso-8859-1'); > encode: 'Ã¼'. > > However, when I try to use the encoded URL with ZnClient > ZnClient new > url: 'http://example.com/%FC'; > get. > > I get a ZnUTF8Encoder>>errorIllegalLeadingByte (Illegal leading byte for utf-8 encoding). > > Any help is greatly appreciated. > > Cheers, > Bernhard > > > >

June 28, 2016

Re: [Pharo-dev] Pharo and Unity

by Dimitris Chloupis

It's one of my priorities for my project Ephestos, but is a low priority. Meaning 5 - 6 years down the road. The technology needs work, but I keep an eye on it. Another thing is that I would prefer something on GPL or at least MIT license. On the other hand nothing stops you from making a Pharo SDK for it. Why not give it a try ? On Mon, 27 Jun 2016 at 19:53, Paul Davidowitz <pdavidow(a)fastmail.fm> wrote: > It would be fantastic if there were a Pharo SDK for Meta which is > powered by Unity (https://www.metavision.com/) Augmented Reality is all > about direct interaction -- the very paradigm of Smalltalk itself. > >

June 28, 2016