- Pharo-dev - lists.pharo.org

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

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

by Tudor Girba

Hi Eliot, I will get back to this email after tomorrow. I need a bit of time to put an answer together. Cheers, Doru > On Jun 27, 2016, at 7:55 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Doru, > > On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Eliot, > > I agree with most things you say (except the conclusion :)), and I think that we are talking about complementary issues. > > As I mentioned before, there already is a need to distinguish between a plain selector and one that is associated with pragmas. This is what you find in PragmaType in Spotter and Inspector. This is a kind of meta-object and having it adds value. I can search for pragmas âtypeâ (we can also call it a PragmaSelector), and I can distinguish between all occurrences of a pragma âtypeâ and its utilization in computation. But, the current implementation of PragmaType is a mere pseudo-meta-object, given that it has no casual connection to the runtime. > > What we know from Smalltalk is that the analysis model does not have to differ from the runtime one. The consequence is that every time we do see a difference, we should investigate because we might uncover a hidden need opportunity. > > I know the VW model, and indeed, we could have something like: > > MyConcept class>>myPragmaDefinition > âa comment about the pragma" > <pragma: #selector> > > However, this only deals with the definition of the pragma type not with the internal representation. There could still well be an object that encapsulates both the selector and the comment. And that object would also allow us to build tools around it. We could call it a PragmaType, PragmaDefinition, or even PragmaSelector. And we could get the Pragma to point to this type either through an inst var or through a query (I would probably prefer an instvar). > > Well, there already /is/ a meta-object called Pragma, and it gets instantiated when one accesses the compiled method via pragmas: > > (CompiledMethod allInstances detect: [:m| m pragmas size > 1]) pragmas collect: [:ea| {ea. ea class}] {{<export: true> . Pragma} . {<var: #tablePtr type: 'int *'> . Pragma}} > > So we could add the information you want to Pragma, and have it be lazy. The Pragma could go search for the defining class-side pragma methods and use the parser to extract the comment(s) when asked. Hence simple access to pragmas, interested only in the selectors for applying, wouldn't have their performance be impacted. > > > I think that this proposition does not remove from the simplicity of the implementation at all, but allows the new needs to be accommodated nicely. The alternative is to not do anything, in which case we will continue to have an analysis-only-pseudo-meta-object which is not nice at all. I do not think we should jump on this lightly, but I do think we should have a critical look and evaluate the options. > > This pseudo-meta-object (Pragma) can sty ill be causally connected, in the same way that a MethodReference can be causally connected. The causation is things like "remove", "recompile", but that's dubious. It's essentially a read-only relationship; one wants to be able to locate the method from the pragma, but changing the method from the pragma isn't necessarily a good idea. Would you agree that convenience methods like "remove" on MethodReference are a bad idea and one should stick to the removeSelector: protocol on Behavior and ClassDescription? > > > What do you think? > > Have I and enough coffee to scramble my thoughts might be a more pertinent question ;-) > > > Cheers, > Doru > > > > On Jun 27, 2016, at 2:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > Hi Doru, > > > >> On Jun 27, 2016, at 3:52 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >> Hi, > >> > >> The CompiledMethod already has a way to retrieve Pragma instances: > >> > >> CompiledMethod>>pragmas. > >> > >> However, the Pragma instance does not have a meta-object associated with it. So, I would first start from adding that one and linking such a PragmaType to its instances. The important thing here would be that all Pragma instances with a certain selector should reference the same PragmaType. > > > > Let me express a dissenting opinion. Our pragma system is minimal yet powerful. By using Message instances (with literal arguments) to represent pragmas we get > > - executable pragmas that can be applied using perform: or wrappers such as sentTo: > > - we can use conventional browsing queries (implementors and senders) to discover which methods are marked by a specific pragma and what pragma-processing tools implement a specific pragma. > > - a rich pragma language that can have many, named parameters > > - a system which doesn't need its own language, but reuses the existing Smalltalk parsing facilities, and so is easier to learn and to implement > > > > So its parsimony is an important part of its virtues. It is minimal. > > > > One thing missing from the Squeak/Pharo implementation is the set of legal pragmas a class accepts. In VisualWorks a class implements the <pragma: #pragma:selector:> (it might be <pragmas: #(pragma:selector:one: pragma:selector:two:)>) to define the legal set of pragmas. [Implementation note, these are /not/ searched for ahead of compilation; instead, the parser delays searching for class-side methods containing pragma: pragmas until it encounters a pragma, and it searches for all class side methods, including in superclasses). > > > > This scheme allows pragmas to be checked; only pragmas in the set of allowed pragmas are accepted, and it allows collision-free extensibility; any package can add a set of legal pragmas to a class merely by choosing a method selector that won't collide with any other containing pragma: pragmas, eg > > kernelPragmas > > <pragma: #primitive:> > > <pragma: #primitive:error:> > > <pragma: #primitive:module:> > > <pragma: #primitive:module:error:> > > > > We're missing this, which means our compilers don't safely check for valid pragmas and can't reject invalid or unrecognized ones, which is error prone. > > > > If we implemented this then we would have a natural place to comment pragmas in the method that defines a particular pragma, one that would be found using senders. > > > > None of this requires a meta object. It is perfectly recursive; using itself to implement itself. I find this very elegant (I didn't invent pragma: pragmas; Steve Dahl did, and it's a cool idea). > > > > So as an inventor of pragmas I'd like to ask for the minimal implementation outlined above. I'd like that we didn't j tricycle a specific meta object, with all the additional tools that implies, and instead stick to the minimalist and parsimony of the original design and use pragmas to comment pragmas. > > > >> Cheers, > >> Doru > > > > Thanks for reading. > > Cheers, Eliot > > > >>> On Jun 27, 2016, at 12:34 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >>> > >>> > >>> 2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >>> Hi, > >>> > >>> That is my proposal as well: introduce a first class entity that describes a Pragma instance. Who would be interested to play with this? > >>> > >>> How it could be done? > >>> Probably compiler could search preferred Pragma class for given selector. And then we will have collection of real pragma instances inside CompiledMethod. What do you think? > >> > >> -- > >> www.tudorgirba.com > >> www.feenk.com > >> > >> "Be rather willing to give than demanding to get." > >> > >> > >> > >> > >> > > > > -- > www.tudorgirba.com > www.feenk.com > > "When people care, great things can happen." > > > > > > > > > -- > _,,,^..^,,,_ > best, Eliot -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

June 28, 2016