Pharo-users
By thread
pharo-users@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
May 2020
- 70 participants
- 337 messages
Re: [Pharo-users] git and Pharo new book...
by Pierce Ng
On Thu, May 14, 2020 at 03:54:31PM +0200, Stéphane Ducasse wrote:
> if you want to contribute to a chapter on other than github solutions.
> I would be happy to help editing such chapter.
>
> If you want to you can do a PR with a chapter.
Sure, I'll do that. I'll start next month Jun 2020.
Pierce
May 15, 2020
Re: [Pharo-users] Deleting images / saving as - in Pharo Launcher auncher
by Christophe Demarey
Hi Cédrick,
> Le 7 mai 2020 à 08:24, Cédrick Béler <cdrick65(a)gmail.com> a écrit :
>
> Hi Christophe,
>
>
> This version is definitely cooler :)
Thanks
> I just wander as for the previous version why deleting image can take some time, whereas itâs quick to delete the image repository. Is it normal ?
In Pharo, deleting files is slow because Pharo visits all the files to delete to check if there are file descriptors opened on these files to close them.
I think it is something that could be improved. In many situations, you know you do not have descriptors on these files and we could have a method to delete without doing the check, just the system call, without visiting the tree.
> Another thing that might help my way of doing things. I like to "save as" the image so as to have a quick check point, and the launcher is not « friendly » with renaming as it loads the default image.
>
> Any idea on how to integrate that ? Maybe having a list of images that pops-up ?
For this feature, I have no good idea for now.
I had in mind to use a tree instead of a list of images. You could expand if there are more than one image and see other images in the folder.
The problem is for the metadata file: we could assume that other images should use the same metadata as the core image and use them to run the image. (For now, the metadata filename is the same for all images).
> I actually changed once the "save as » in a « save checkpoint charly » where it saves a copy but still load the default name. Might be an option ? :)
« Saves a copy » : do you mean you copy the full folder to another name ?
Cheers,
Christophe
May 14, 2020
Re: [Pharo-users] Artefact: special characters related issue
by Sabine Manaa
Hi Evelyn,
Look here:
http://forum.world.st/Artefact-and-WideString-td4857147.html#a4857325
Greetings
Sabine
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
May 14, 2020
Re: [Pharo-users] Siren 9.0 Released
by Stéphane Ducasse
Thanks Steven this is cool to see that Siren is living and kicking.
Last year I was browsing the old site and I was sad because I thought it was dead.
Your OSC looks better than the one in Pharo even if we used it successfully to connect interactive tables with a HCI research group.
If you need help to migrate from VW let us know because it would be great to have Siren working in Pharo.
I did not see any Unit tests and the tests saved us when we migrated Moose. Sometimes we even only kept them because they were
better than the implementation. It took us around six months and we got free :)
And we have some contacts that would be interested in London. We could put you in contact.
Now just some questions and you may know the answer so I ask
I was thinking but I may be totally wrong that it was forbidden to give VW images and that the current license
was for personal use only. Long time ago the shrink process was removing the compiler. Now I saw that your image is 42mb.
Personally I do not want to download any VisualWorks distribution and sign their licenses because I want to stay cristal clear
on ANY license and possible issues. I did not look at Visualworks since 2008 and I feel clean and I will stay like that.
So I imagine that Iâm not allowed to use your software. Iâm not good in music sadly so there is no frustration from my side.
You mention that people can use a non-commercial version of VW but this license does not exist anymore.
Is there a 64 bits version of VW because VW7.5 starts to show its age and on recent mac you only have 64 bits.
Some people may think that we are just over the top on open-source but this is not by accident that we took the responsibility to create Pharo.
We could not distribute Moose our open-source platform so after 10 years of hard work we had to do something. And we created Pharo.
And the problem we got were with the previous version (the non commercial) of the Cincom license and the new one is even more restrictive.
Some friends of mine told me that some lawyers were starting to get picky and send letters around.
So watch out.
BTW I did not see the license of Siren on the git repo. If I may suggest one,
BSD/MIT are nice, avoid GPL because it means that nobody serious on Smalltalk will ever look at your system and contribute.
S.
> On 14 May 2020, at 01:40, stephen(a)heaveneverywhere.com wrote:
>
>
> Hello all,
>
> The Siren system is a general-purpose framework for music and sound composition, processing, performance, and analysis; it is a collection of about 350 classes written in Smalltalk-80 (40 kLOC or so). Siren 9.0 works on VisualWorks Smalltalk (though the bulk has been ported to other dialects as well); Siren supports streaming I/O via OpenSoundControl (OSC), MIDI, and multi-channel audio ports. The Siren release is available via the web from the URL http://FASTLabInc.com/Siren <http://fastlabinc.com/Siren>.
>
> Siren is a programming framework and tool kit; the intended audience is Smalltalk developers, or users willing to learn Smalltalk in order to write their own applications. The built-in applications are meant as demonstrations of the use of the libraries, rather than as end-user applications. Siren is not a MIDI sequencer, nor a score notation editor, through both of these applications would be easy to implement with the Siren framework.
>
> There are several elements to Siren:
>
> * the Smoke music representation language (music magnitudes, events, event lists, generators, functions, and sounds);
>
> * voices, schedulers and I/O drivers (real-time and file-based voices, sound, score file, OSC, and MIDI I/O);
>
> * user interface components for musical applications (UI framework, tools, and widgets);
>
> * several built-in applications (editors and browsers for Smoke objects); and
>
> * external library interfaces for streaming I/O and DSP math (sound/MIDI I/O, fast FFT, CSL & Loris sound analysis/resynthesis packages )
>
> The best in-depth doc (book chapter) is in,
> http://FASTLabInc.com/Siren/Doc/SirenBookChapter.pdf <http://fastlabinc.com/Siren/Doc/SirenBookChapter.pdf>
>
> The read the demo code workbook (this text), go to,
> http://FASTLabInc.com/Siren/Siren7.5.Workbook.html <http://fastlabinc.com/Siren/Siren7.5.Workbook.html>
> or
> http://FASTLabInc.com/Siren/Siren7.5.Workbook.pdf <http://fastlabinc.com/Siren/Siren7.5.Workbook.pdf>
>
> If you like to read manuals, take a look at,
> http://FASTLabInc.com/Siren/Manual <http://fastlabinc.com/Siren/Manual>
>
> or watch the detailed Siren demo at,
> https://vimeo.com/120751122 <https://vimeo.com/120751122>
>
> The links to get Siren9 are,
>
> Web site: http://fastlabinc.com/Siren <http://fastlabinc.com/Siren>
>
> Package download: http://fastlabinc.com/Siren/Siren_9.0.zip <http://fastlabinc.com/Siren/Siren_9.0.zip>
>
> Github repo: https://github.com/stpope/Siren9 <https://github.com/stpope/Siren9>
>
>
> Comments solicited.
>
> Stephen Pope
>
>
> --
>
> Stephen Travis Pope Santa Barbara, California, USA
> <pastedGraphic.tiff> http://HeavenEverywhere.com <http://heaveneverywhere.com/> http://FASTLabInc.com <http://fastlabinc.com/>
> https://vimeo.com/user19434036/videos <https://vimeo.com/user19434036/videos> http://heaveneverywhere.com/Reflections <http://heaveneverywhere.com/Reflections>
>
> --
>
>
>
--------------------------------------------
Stéphane Ducasse
http://stephane.ducasse.free.fr / http://www.pharo.org
03 59 35 87 52
Assistant: Julie Jonas
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France
May 14, 2020
Re: [Pharo-users] [ANN] Pharo Compendium
by Torsten Bergmann
Hi Cédrick,
The GitHub part is based on an open public GitHub HTTP query - which has some limits:
 - it does not return private repos, only public ones
 - it has a rate limit to not bring servers down
Maybe there is a way to overcome these limits via authentication, yes. But most of my projects are
public - so for me this was not a problem yet. And the initial idea of Compendium is to find public
resources available to all users - not private ones available to single ones.
Â
If time permits I might look into this ... but not now.
Bye
T.
Gesendet:Â Donnerstag, 14. Mai 2020 um 13:02 Uhr
Von: "Cédrick Béler" <cdrick65(a)gmail.com>
An:Â "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>
Betreff:Â Re: [Pharo-users] [ANN] Pharo Compendium
Really great tool Torsten :)
Â
I tagged some of my repo to test. I reseted the stores because they wasnât showing. It seems to load but then when querying in spotter, I got an error message because of non authentification.
Â
I went in in the (iceberg) settings, checked then unchecked the default RSA keys directory (by the way is it a know bug or is it just me ?).
Â
It worked after, I mean no error when querying spotter.
Â
Still I donât see my projects. Iâll try later but if you have an idea...
Â
Â
Cheers,
Cédrick
Â
Le 12 mai 2020 à 16:35, Torsten Bergmann <astares@gmx.de[mailto:astares@gmx.de]> a écrit :Â
Hi Sven,
I added spotter search now. I prefixed the github spotter entries additionally with the user name (owner).
This way you will be able to quickly find tagged public projects by keying in the project and/or username.
See attached picture for an example.
Catalog loading is possible via spotter too.
Have fun
T.
 Gesendet: Mittwoch, 06. Mai 2020 um 14:24 Uhr
Von: "Sven Van Caekenberghe" <sven@stfx.eu[mailto:sven@stfx.eu]>
An: "Any question about pharo is welcome" <pharo-users@lists.pharo.org[mailto:pharo-users@lists.pharo.org]>
Betreff: Re: [Pharo-users] [ANN] Pharo Compendium
Great work, Torsten, works like a charm !
Since all Github projects have a README.md maybe that could be used as well, it will certainly contain more information.
Most projects have several keyswords as well, that could be useful to show.
Also, why not add a 'clone & metacello install baseline of' command ?
Another idea: allow spotter searching of the pharo compendium entries ?
Sven
 On 2 May 2020, at 22:34, Torsten Bergmann <astares@gmx.de[mailto:astares@gmx.de]> wrote:
Hi,
time flows and Pharo-Project is improving on all ends since its inception in 2008. As you know over time for the code project hosting we used
SqueakSource, SS3 repos and other and later switched to SmalltalkHub available on http://smalltalkhub.com[http://smalltalkhub.com].
Starting with Iceberg in Pharo 6 many community projects are now hosted elsewhere - most of them moved to GitHub. Pharo's git support allows
also for GitLab, BitBucket and other git hosting services.
I still think easy and quick accessibility to external (re)sources directly from the image is key - especially for new users who often get lost
among all the various things that are available. Back in 2013 I therefore provided a small tool called ConfigBrowser as a replacement for
MetacelloConfigurationBrowser to easily load Metacello configs directly into Pharo.
Later we improved quick loading with a primary tool called "Catalog" written by Esteban. Catalog is indexing every 24 hours all configs within
specific meta-repositories on SmalltalkHub (per Pharo version) like
http://www.smalltalkhub.com/#!/~Pharo/MetaRepoForPharo80[http://www.smallta…
to automatically build
 http://catalog.pharo.org/[http://catalog.pharo.org/]
and also a JSON source
 http://catalog.pharo.org/catalog/json[http://catalog.pharo.org/catalog/json]
The last one feeds the catalog browser and catalog spotter search within the Pharo image.
So Catalog helped us and especially new Pharo users to find what is available as external project or package. Unfortunately some package maintainers
are too lazy and do not maintain their configs over old and new Pharo versions. Also SmalltalkHub.com[http://SmalltalkHub.com] is now seen as legacy and will only be available
in a read only mode or as a browseable archive soon.
So we have to think about others steps beyond Catalog and (triggered by a recent discussion on Discord) I started now a simple tool that helped me
finding all GitHub projects marked with "pharo" as GitHub topic. I additionally also added previous catalog loading. More sources could be added
as well as some kind of custom stores/plugins. Maybe this tool could be the base for a future replacement of the catalog tool.
Long story short - let me introduce "Pharo Compendium":
Compendium is a new UI tool to list, browse and load Pharo artefacts from the web like:
- GitHub Projects
- Catalog Projects
and other
By default there are two plugin packages available for GitHub and Catalog - but you can implement own ones easily to connect to other sources
on the web. Compendium is available on:
 https://github.com/astares/Pharo-Compendium[https://github.com/astares/Phar…
It is implemented using the new Spec2 UI framework - so you need a recent Pharo 9 image to give it a try. Just run:
  Metacello new
repository: 'github://astares/Pharo-Compendium/src';
baseline: 'Compendium';
load
to load the tool. Then go to "Tools" -> "Compendium Browser". Attached is a screenshot demoing the primary functionality.
If you want your GitHub project to be listed in the tool you simply need to add the topic "pharo" to the GitHub repository on the GitHub webpage.
Feel free to comment or help improving the tool by sending PR's.
Thx
T. (aka astares)
<compendium.png>
 <Compendium_Spotter.jpg>
May 14, 2020
Covid-19 Tracker with PharoJS
by Noury Bouraqadi
Hi,
Dave Mason did implement a COVID-19 tracker with PharoJS.
https://covid.cs.ryerson.ca/compare/ <https://covid.cs.ryerson.ca/compare/>
Noury
May 14, 2020
Re: [Pharo-users] Pharo-Sound
by Russ Whaley
Great! I'll try that. Thank you!
Any other ideas just to get the computer to beep? In the old days I could
send a ^G to stdout, lol... (or something like that, memory fades).
On Thu, May 14, 2020 at 9:56 AM Stéphane Ducasse <stephane.ducasse(a)inria.fr>
wrote:
>
>
> On 14 May 2020, at 15:44, Russ Whaley <whaley.russ(a)gmail.com> wrote:
>
> Okay, so I may just have a compatibility issue w/v8, I suppose. The
> suggestions on external audio, etc., are great - and a future need for me
> for sure, but right now, I'd settle for a beep :) - as I'm having troubles
> (another post on Spec2) updating my display with a 'Correct' or 'Incorrect'
> - between normal refreshes... so I just wanted an audible beep to let me
> know things were working. I created a Logger class where I can log and see
> (in the log) that all the functional code is getting processed properly - I
> just can't seem to get it to the display.
>
> I may try the FFI route - but it looks to be quite a bit more than I need
> right now.
>
> Is there a way to completely remove the PharoSound 'package'? It's
> possible, with me trying to figure out how to use it, I ran something that
> disabled it in my version. Reloading it didn't help, but perhaps if I
> could get it completely deleted?
>
>
> go the repository browser, select it and press unload.
>
> S/
>
>
> Thanks all!
> Russ
>
> On Thu, May 14, 2020 at 9:36 AM Stéphane Ducasse <
> stephane.ducasse(a)inria.fr> wrote:
>
>> Hi russ
>>
>> I do not know if the catalog is referring the latest version but in
>> anycase the plugins are all using old libraries and do not really work
>> anymore (because not
>> available anymore).
>>
>> We were discussing monday about it and to propose a binding to more
>> recent libraries such as openAV
>> We need help there.
>>
>> S.
>>
>> On 13 May 2020, at 20:49, Russ Whaley <whaley.russ(a)gmail.com> wrote:
>>
>> I'm using Pharo 8 stable (64bit) version.
>>
>> I pulled PharoSound from the Catalog and installed. Installed fine, no
>> errors.
>>
>> I went to the comments on the abstract class. Copied the examples to the
>> Playground, ran them - worked fine (although I don't know how to stop the
>> dang PluckedString example!!)... I digress :)
>>
>> I created my own subclass to play specific sounds at certain events in my
>> application. Worked well. A day later - I have no sound in my image at
>> all now. Nothing works. I reinstalled from the Catalog. Ran the code
>> listed in the AbstractSound comments - nothing.
>>
>> I installed a new Pharo 8 stable 64-bit image - pulled PharoSound in,
>> copied the sampe code from AbstractSound comments... and it worked just
>> fine.
>>
>> Any ideas how I can get sound to work again on my original image? For
>> me, it is a real pain to try and migrate all my code over to a new image.
>> It is apparently a character flaw on my part, but it takes me hours to get
>> Git/Iceberg working properly on a new image. (yes, I'm ashamed). I see a
>> new book on the topic, but I had been following that book while it was wip,
>> and Git/Iceberg just whips my butt. But if going to a new image is the
>> solution, I'll try, try again.
>>
>> What do you think?
>>
>> Thanks,
>> Russ
>>
>> --
>> Russ Whaley
>> whaley.russ(a)gmail.com
>>
>>
>> --------------------------------------------
>> Stéphane Ducasse
>> http://stephane.ducasse.free.fr / http://www.pharo.org
>> 03 59 35 87 52
>> Assistant: Julie Jonas
>> FAX 03 59 57 78 50
>> TEL 03 59 35 86 16
>> S. Ducasse - Inria
>> 40, avenue Halley,
>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>> Villeneuve d'Ascq 59650
>> France
>>
>>
>
> --
> Russ Whaley
> whaley.russ(a)gmail.com
>
>
> --------------------------------------------
> Stéphane Ducasse
> http://stephane.ducasse.free.fr / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
>
--
Russ Whaley
whaley.russ(a)gmail.com
May 14, 2020
Artefact: special characters related issue
by EVELYN CUSI LOPEZ
Hello all,
We are working with artefact, but we have a problem when using special
characters in text, since when entering text with special characters
(i.e.cçÄÄeéeèëêÄÄ ) the PDF is generated in white. Below, you may find a
small example to replicate this error:
-=-=-==-=-=-==-=-=-==-=-=-==-=-=-==-=-=-== PDFDemos class >>
specialCharacterTest "PDFDemos specialCharacterTest" <script> self new
specialCharacterTest: (self streamNamed: 'specialCharacterTest.pdf')
PDFDemos >> specialCharacterTest: aStream | pdfdoc aPage | pdfdoc :=
PDFDocument new. aPage := PDFPage new. aPage add: (PDFTextElement new from:
20 mm @ 82 mm; text: 'cçÄÄeéeèëêÄÄ'). pdfdoc add: aPage. pdfdoc exportTo:
aStream -=-=-==-=-=-==-=-=-==-=-=-==-=-=-==-=-=-== We have already tried
different types of encoding, without success since we only obtain text with
empty spaces or with foreign characters - Do you have any clue to address
this error? Any help is very welcome, thanks [image: :slight_smile:]
May 14, 2020
Re: [Pharo-users] mentor question 4
by Stéphane Ducasse
thanks this is interesting.
S.
> On 12 May 2020, at 07:12, Richard O'Keefe <raoknz(a)gmail.com> wrote:
>
> For what it's worth, here's a moderately thorough examination of several
> different Smalltalk systems.
> Let A = astc, D = Dolphin, G = GNU Smalltalk, Q = Squeak,
> S = ANSI standard, T = Strongtalk, V = VisualWorks, X = ST/X
>
> #asString
>
> ADGPQST!X Character => String with: self
> ADGPQSTVX String => self
> ADGPQSTVX Symbol => String withAll: self
> ......... Text/Paragraph, where provided, => underlying string.
> A-G-----X Collection => String withAll: self
> ---PQ---- Collection => self printString
> A........ ByteArray => "decoded as Unicode"
> .DGPQ-TVX ByteArray => "decoded as Latin1"
> ADG.Q..VX Filename => "unparse (Filename, FilePath, whatever)
> AdgpQ.TVX URI => "unparse (ZnUrl in P)
> Ad.PQ...X UUID => "unparse (d, GUID equivalent)"
> .DGpq...X Number => self displayString "or self printString, maybe via Object"
> ...PQ...X Object => self printString
>
> There's a rough consensus here:
> - if something *is* textual (Character, String, Symbol, Text,
> Paragraph) #asString returns it as a normal string
> - if something is a parsed form of structured text (file name,
> URI, UUID) its unparsed form is returned, converting it back
> should yield an equal parsed form
> - if something is a byte array, it may be converted to a string
> (the rule is to preserve the bytes, my library presumes byte
> arrays are UTF8-encoded)
> - if numbers are accepted at all, their #printString is returned
> - if is none of the above, but has a #name or #title, that is
> commonly the result.
>
> The open question is what converting an array of characters using
> #asString will do. There is at least one Smalltalk out there
> where #(65 66 67) asString => 'ABC', but that's a step further
> than I personally want, though it is consistent with ByteArray.
>
>
>
>
> On Tue, 12 May 2020 at 11:16, Jerry Kott <jkott(a)image-ware.com <mailto:jkott@image-ware.com>> wrote:
> Hi all,
>
> Iâve been lurking so far, but I must add my voice here and agree with Richard.
>
> The malleability of Smalltalk tempts people into implementing #asString, #name, and similar semantically ambiguous method names. Like Richard, I regretted every single time I (or someone else on my team before me) decided to use these. It goes back to âSmalltalk with Styleâ (probably the best little red book you could ever own): write intention revealing code whenever you can, and comment liberally when you canât.
>
> Jerry Kott
> This message has been digitally signed.
> PGP Fingerprint:
> A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5
>
>
>
>> On 11-05-2020, at 2:48 PM, Richard Sargent <rsargent(a)5x5.on.ca <mailto:rsargent@5x5.on.ca>> wrote:
>>
>>
>>
>> On May 11, 2020 2:19:49 PM PDT, Richard O'Keefe <raoknz(a)gmail.com <mailto:raoknz@gmail.com>> wrote:
>>> I was saying that I expected #($a $b $c) asString ==> 'abc'.
>>
>> Over the years, I found myself being opposed to the idea that all objects can sensibly have an #asString implementation. When it's been done, it ultimately caused more problems than it solved.
>>
>> Consider $(48 49 50) asString. Do you expect it to give you a string with all the digits? Or perhaps it's meant to interpret the elements as byte-like things, as you would need for "String withAll: aCollection". So, the numbers could be interpreted as codepoints, as they are in a ByteArray.
>>
>> But, what does "(Array with: Object new with: ProcessScheduler) asString" mean?
>>
>> It seems to me that having all objects understand #asString leads to confusion.
>>
>> If you want an array to print as its literal representation, implement #printAsLiteral, so that your intention is clear.
>>
>>
>>> If you want something that can be read back, that's what #storeString
>>> is for,
>>>
>>> On Tue, 12 May 2020 at 01:28, Stéphane Ducasse
>>> <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote:
>>>>
>>>>
>>>>
>>>> On 5 May 2020, at 16:16, Richard O'Keefe <raoknz(a)gmail.com <mailto:raoknz@gmail.com>> wrote:
>>>>
>>>> By the way, while playing with this problem, I ran into a moderately
>>>> painful issue.
>>>>
>>>> There is a reason that Smalltalk has both #printString (to get a
>>>> printable representation of an object) and #asString (to convert a
>>>> sequence to another kind of sequence with the same elements.) If I
>>>> *want* #printString, I know where to find it. The definition in my
>>>> Smalltalk no reads
>>>>
>>>> asString
>>>> "What should #($a $b $c) do?
>>>> - Blue Book, Inside Smalltalk, Apple Smalltalk-80:
>>>> there is no #asString.
>>>> - ANSI, VW, Dolphin, CSOM:
>>>> #asString is defined on characters and strings
>>>> (and things like file names and URIs that are sort of
>>> strings),
>>>> so expect an error report.
>>>> - VisualAge Smalltalk:
>>>> '($a $b $c)'
>>>> - Squeak and Pharo:
>>>> '#($a $b $c)'
>>>> - GNU Smalltalk, Smalltalk/X, and astc:
>>>> 'abc'
>>>> I don't intend any gratuitous incompatibility, but when there
>>>> is no consensus to be compatible with, one must pick something,
>>>> and this seems most useful.
>>>> "
>>>> ^String withAll: self
>>>>
>>>> Does anyone here know WHY Squeak and Pharo do what they do here?
>>>>
>>>>
>>>> Oops I did not see the quotes on my screen..
>>>>
>>>> #( a b c) asString
>>>>>>> '#(#a #b #c)â
>>>>
>>>> this is unclear to me why this is not good but I have no strong
>>> opinion
>>>> that this is good.
>>>>
>>>> I worked on printString for literals because I wanted to have
>>>> self evaluating properties for basic literal like in Scheme and
>>> others.
>>>> where
>>>> #t
>>>>>>>
>>>> #t
>>>>
>>>> And I payed attention that we get the same for literal arrays.
>>>> Now the conversion is open to me.
>>>>
>>>> #($a $b $c) asString
>>>>>>>
>>>> '#($a $b $c)â
>>>>
>>>> In fact I do not really understand why a string
>>>>
>>>> #($a $b $c) asString would be '(a b c)â
>>>> and its use
>>>> if this is to nicely display in the ui I would have
>>>> displayString doing it.
>>>>
>>>> S.
>>>>
>>>>
>>>>
>>>> On Wed, 6 May 2020 at 01:20, Richard O'Keefe <raoknz(a)gmail.com <mailto:raoknz@gmail.com>>
>>> wrote:
>>>>
>>>>
>>>> The irony is that the code I was responding to ISN'T obviously
>>> correct.
>>>> Indeed, I found it rather puzzling.
>>>> The problem specification says that the input string may contain
>>> digits
>>>> AND SPACES. The original message includes this:
>>>>
>>>> Strings of length 1 or less are not valid. Spaces are allowed in the
>>>> input, but they should be stripped before checking. All other
>>>> non-digit characters are disallowed.
>>>>
>>>> Now it isn't clear what "disallowed" means. I took it to mean "may
>>> occur and
>>>> should simply mean the input is rejected as invalid." Perhaps "may
>>> not occur"
>>>> was the intention. So we shall not quibble about such characters.
>>>>
>>>> But I can't for the life of me figure out how Trygve's code checks
>>> for spaces.
>>>> One reason this is an issue is that the behaviour of #digitValue is
>>> not
>>>> consistent between systems.
>>>> Character space digitValue
>>>> does not exist in the ANSI standard
>>>> answers -1 in many Smalltalks (which is a pain)
>>>> answers a positive integer that can't be mistake for a digit in my
>>> Smalltalk
>>>> raises an exception in some Smalltalks.
>>>>
>>>> This is a comment I now have in my Smalltalk library for #digitValue
>>>> "This is in the Blue Book, but unspecified on non-digits.
>>>> Squeak, Pharo, Dolphin, VW, VAST, and Apple Smalltalk-80
>>>> answer -1 for characters that are not digits (or ASCII
>>> letters),
>>>> which is unfortunate but consistent with Inside Smalltalk
>>>> which specifies this result for non-digits.
>>>> ST/X and GST raise an exception which is worse.
>>>> Digitalk ST/V documentation doesn't specify the result.
>>>> This selector is *much* easier to use safely if it
>>>> returns a 'large' (>= 36) value for non-digits."
>>>>
>>>> Let's compare three versions, the two I compared last time,
>>>> and the "version A" code I discussed before, which to my mind
>>>> is fairly readable.
>>>>
>>>> "Don't add slowness": 1 (normalised time)
>>>> "Trygve's code": 6.5
>>>> "High level code": 30.6 (or 4.7 times slower than Trygve's)
>>>>
>>>> Here's the "High level code".
>>>> ^(aString allSatisfy: [:each | each isSpace or: [each isDigit]])
>>> and: [
>>>> |digitsReverse|
>>>> digitsReverse := (aString select: [:each | each isDigit])
>>> reverse.
>>>> digitsReverse size > 1 and: [
>>>> |evens odds evenSum oddSum|
>>>> odds := digitsReverse withIndexSelect: [:y :i | i odd].
>>>> evens := digitsReverse withIndexSelect: [:x :i | i even].
>>>> oddSum := odds detectSum: [:y | y digitValue].
>>>> evenSum := evens detectSum: [:x |
>>>> #(0 2 4 6 8 1 3 5 7 9) at: x digitValue + 1].
>>>> (oddSum + evenSum) \\ 10 = 0]]
>>>>
>>>> This is the kind of code I was recommending that Roelof write.
>>>>
>>>> As a rough guide, by counting traversals (including ones inside
>>> existing
>>>> methods), I'd expect the "high level" code to be at least 10 times
>>> slower
>>>> than the "no added slowness" code.
>>>>
>>>> We are in vehement agreement that there is a time to write high level
>>>> really obvious easily testable and debuggable code, and that's most
>>>> of the time, especially with programming exercises.
>>>>
>>>> I hope that we are also in agreement that factors of 30 (or even 6)
>>>> *can* be a serious problem. I mean, if I wanted something that slow,
>>>> I'd use Ruby.
>>>>
>>>> I hope we are also agreed that (with the exception of investigations
>>>> like this one) the time to hack on something to make it faster is
>>> AFTER
>>>> you have profiled it and determined that you have a problem.
>>>>
>>>> But I respectfully suggest that there is a difference taking slowness
>>> OUT
>>>> and simply not going out of your way to add slowness in the first
>>> place.
>>>>
>>>> I'd also like to remark that my preference for methods that traverse
>>> a
>>>> sequence exactly once has more to do with Smalltalk protocols than
>>>> with efficiency. If the only method I perform on an object is #do:
>>>> the method will work just as well for readable streams as for
>>>> collections. If the only method I perform on an object is
>>> #reverseDo:
>>>> the method will work just as well for Read[Write]Streams as for
>>>> SequenceReadableCollections, at least in my library. It's just like
>>>> trying to write #mean so that it works for Durations as well as
>>> Numbers.
>>>>
>>>> Oh heck, I suppose I should point out that much of the overheads in
>>>> this case could be eliminated by a Self-style compiler doing dynamic
>>>> inlining + loop fusion. There's no reason *in principle*, given
>>> enough
>>>> people, money, and time, that the differences couldn't be greatly
>>>> reduced in Pharo.
>>>>
>>>> On Tue, 5 May 2020 at 21:50, Trygve Reenskaug <trygver(a)ifi.uio.no <mailto:trygver@ifi.uio.no>>
>>> wrote:
>>>>
>>>>
>>>> Richard,
>>>>
>>>> Thank you for looking at the code. It is comforting to learn that the
>>> code has been executed for a large number of examples without breaking.
>>> The code is not primarily written for execution but for being read and
>>> checked by the human end user. It would be nice if we could also check
>>> that it gave the right answers, but I don't know how to do that.
>>>>
>>>> The first question is: Can a human domain expert read the code and
>>> sign their name for its correctness?
>>>>
>>>>
>>>> When this is achieved, a programming expert will transcribe the first
>>> code to a professional quality program. This time, the second code
>>> should be reviewed by an independent programmer who signs their name
>>> for its correct transcription from the first version.
>>>>
>>>> --Trygve
>>>>
>>>> PS: In his 1991 Turing Award Lecture, Tony Hoare said: "There are two
>>> ways of constructing a software design: One way is to make it so simple
>>> that there are obviously no deficiencies and the other is to make it so
>>> complicated that there are no obvious deficiencies. The first method is
>>> far more difficult."
>>>>
>>>> --Trygve
>>>>
>>>> On tirsdag.05.05.2020 04:41, Richard O'Keefe wrote:
>>>>
>>>> As a coding experiment, I adapted Trygve Reenskoug's code to my
>>>> Smalltalk compiler, put in my code slightly tweaked, and benchmarked
>>>> them on randomly generated data.
>>>>
>>>> Result: a factor of 6.3.
>>>>
>>>> In Squeak it was a factor of ten.
>>>>
>>>> I had not, in all honesty, expected it to to be so high.
>>>>
>>>> On Tue, 5 May 2020 at 02:00, Trygve Reenskaug <trygver(a)ifi.uio.no <mailto:trygver@ifi.uio.no>>
>>> wrote:
>>>>
>>>> A coding experiment.
>>>> Consider a Scrum development environment. Every programming team has
>>> an end user as a member.
>>>> The team's task is to code a credit card validity check.
>>>> A first goal is that the user representative shall read the code and
>>> agree that it is a correct rendering of their code checker:
>>>>
>>>> luhnTest: trialNumber
>>>> | s1 odd s2 even charValue reverse |
>>>> -----------------------------------------------
>>>> " Luhn test according to Rosetta"
>>>> "Reverse the order of the digits in the number."
>>>> reverse := trialNumber reversed.
>>>> "Take the first, third, ... and every other odd digit in the reversed
>>> digits and sum them to form the partial sum s1"
>>>> s1 := 0.
>>>> odd := true.
>>>> reverse do:
>>>> [:char |
>>>> odd
>>>> ifTrue: [
>>>> s1 := s1 + char digitValue.
>>>> ].
>>>> odd := odd not
>>>> ].
>>>> "Taking the second, fourth ... and every other even digit in the
>>> reversed digits:
>>>> Multiply each digit by two and sum the digits if the answer is
>>> greater than nine to form partial sums for the even digits"
>>>> "The subtracting 9 gives the same answer. "
>>>> "Sum the partial sums of the even digits to form s2"
>>>> s2 := 0.
>>>> even := false.
>>>> reverse do:
>>>> [:char |
>>>> even
>>>> ifTrue: [
>>>> charValue := char digitValue * 2.
>>>> charValue > 9 ifTrue: [charValue := charValue -
>>> 9].
>>>> s2 := s2 + charValue
>>>> ].
>>>> even := even not
>>>> ].
>>>> "If s1 + s2 ends in zero then the original number is in the form of a
>>> valid credit card number as verified by the Luhn test."
>>>> ^(s1 + s2) asString last = $0
>>>> ---------------------------------
>>>> Once this step is completed, the next step will be to make the code
>>> right without altering the algorithm (refactoring). The result should
>>> be readable and follow the team's conventions.
>>>>
>>>>
>>>> P.S. code attached.
>>>>
>>>>
>>>> --
>>>>
>>>> The essence of object orientation is that objects collaborate to
>>> achieve a goal.
>>>> Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:trygver@ifi.uio.no>
>>>> Morgedalsvn. 5A http://folk.uio.no/trygver/ <http://folk.uio.no/trygver/>
>>>> N-0378 Oslo http://fullOO.info <http://fulloo.info/>
>>>> Norway Tel: (+47) 468 58 625
>>>>
>>>>
>>>>
>>>> --------------------------------------------
>>>> Stéphane Ducasse
>>>> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / http://www.pharo.org <http://www.pharo.org/>
>>>> 03 59 35 87 52
>>>> Assistant: Julie Jonas
>>>> FAX 03 59 57 78 50
>>>> TEL 03 59 35 86 16
>>>> S. Ducasse - Inria
>>>> 40, avenue Halley,
>>>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>>>> Villeneuve d'Ascq 59650
>>>> France
>>>>
>>
>>
>
--------------------------------------------
Stéphane Ducasse
http://stephane.ducasse.free.fr / http://www.pharo.org
03 59 35 87 52
Assistant: Julie Jonas
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France
May 14, 2020
Re: [Pharo-users] mentor question 4
by Stéphane Ducasse
> On 11 May 2020, at 23:48, Richard Sargent <rsargent(a)5x5.on.ca> wrote:
>
>
>
> On May 11, 2020 2:19:49 PM PDT, Richard O'Keefe <raoknz(a)gmail.com> wrote:
>> I was saying that I expected #($a $b $c) asString ==> 'abc'.
>
> Over the years, I found myself being opposed to the idea that all objects can sensibly have an #asString implementation. When it's been done, it ultimately caused more problems than it solved.
I agree and I would like to clean this situation.
I would like to use displayString when you want to show something in UI element.
printString for a limited UI for debugging purposes.
> Consider $(48 49 50) asString. Do you expect it to give you a string with all the digits? Or perhaps it's meant to interpret the elements as byte-like things, as you would need for "String withAll: aCollection". So, the numbers could be interpreted as codepoints, as they are in a ByteArray.
>
> But, what does "(Array with: Object new with: ProcessScheduler) asString" mean?
> It seems to me that having all objects understand #asString leads to confusion.
>
> If you want an array to print as its literal representation, implement #printAsLiteral, so that your intention is clear.
+ 1000
S
>> If you want something that can be read back, that's what #storeString
>> is for,
>>
>> On Tue, 12 May 2020 at 01:28, Stéphane Ducasse
>> <stephane.ducasse(a)inria.fr> wrote:
>>>
>>>
>>>
>>> On 5 May 2020, at 16:16, Richard O'Keefe <raoknz(a)gmail.com> wrote:
>>>
>>> By the way, while playing with this problem, I ran into a moderately
>>> painful issue.
>>>
>>> There is a reason that Smalltalk has both #printString (to get a
>>> printable representation of an object) and #asString (to convert a
>>> sequence to another kind of sequence with the same elements.) If I
>>> *want* #printString, I know where to find it. The definition in my
>>> Smalltalk no reads
>>>
>>> asString
>>> "What should #($a $b $c) do?
>>> - Blue Book, Inside Smalltalk, Apple Smalltalk-80:
>>> there is no #asString.
>>> - ANSI, VW, Dolphin, CSOM:
>>> #asString is defined on characters and strings
>>> (and things like file names and URIs that are sort of
>> strings),
>>> so expect an error report.
>>> - VisualAge Smalltalk:
>>> '($a $b $c)'
>>> - Squeak and Pharo:
>>> '#($a $b $c)'
>>> - GNU Smalltalk, Smalltalk/X, and astc:
>>> 'abc'
>>> I don't intend any gratuitous incompatibility, but when there
>>> is no consensus to be compatible with, one must pick something,
>>> and this seems most useful.
>>> "
>>> ^String withAll: self
>>>
>>> Does anyone here know WHY Squeak and Pharo do what they do here?
>>>
>>>
>>> Oops I did not see the quotes on my screen..
>>>
>>> #( a b c) asString
>>>>>> '#(#a #b #c)â
>>>
>>> this is unclear to me why this is not good but I have no strong
>> opinion
>>> that this is good.
>>>
>>> I worked on printString for literals because I wanted to have
>>> self evaluating properties for basic literal like in Scheme and
>> others.
>>> where
>>> #t
>>>>>>
>>> #t
>>>
>>> And I payed attention that we get the same for literal arrays.
>>> Now the conversion is open to me.
>>>
>>> #($a $b $c) asString
>>>>>>
>>> '#($a $b $c)â
>>>
>>> In fact I do not really understand why a string
>>>
>>> #($a $b $c) asString would be '(a b c)â
>>> and its use
>>> if this is to nicely display in the ui I would have
>>> displayString doing it.
>>>
>>> S.
>>>
>>>
>>>
>>> On Wed, 6 May 2020 at 01:20, Richard O'Keefe <raoknz(a)gmail.com>
>> wrote:
>>>
>>>
>>> The irony is that the code I was responding to ISN'T obviously
>> correct.
>>> Indeed, I found it rather puzzling.
>>> The problem specification says that the input string may contain
>> digits
>>> AND SPACES. The original message includes this:
>>>
>>> Strings of length 1 or less are not valid. Spaces are allowed in the
>>> input, but they should be stripped before checking. All other
>>> non-digit characters are disallowed.
>>>
>>> Now it isn't clear what "disallowed" means. I took it to mean "may
>> occur and
>>> should simply mean the input is rejected as invalid." Perhaps "may
>> not occur"
>>> was the intention. So we shall not quibble about such characters.
>>>
>>> But I can't for the life of me figure out how Trygve's code checks
>> for spaces.
>>> One reason this is an issue is that the behaviour of #digitValue is
>> not
>>> consistent between systems.
>>> Character space digitValue
>>> does not exist in the ANSI standard
>>> answers -1 in many Smalltalks (which is a pain)
>>> answers a positive integer that can't be mistake for a digit in my
>> Smalltalk
>>> raises an exception in some Smalltalks.
>>>
>>> This is a comment I now have in my Smalltalk library for #digitValue
>>> "This is in the Blue Book, but unspecified on non-digits.
>>> Squeak, Pharo, Dolphin, VW, VAST, and Apple Smalltalk-80
>>> answer -1 for characters that are not digits (or ASCII
>> letters),
>>> which is unfortunate but consistent with Inside Smalltalk
>>> which specifies this result for non-digits.
>>> ST/X and GST raise an exception which is worse.
>>> Digitalk ST/V documentation doesn't specify the result.
>>> This selector is *much* easier to use safely if it
>>> returns a 'large' (>= 36) value for non-digits."
>>>
>>> Let's compare three versions, the two I compared last time,
>>> and the "version A" code I discussed before, which to my mind
>>> is fairly readable.
>>>
>>> "Don't add slowness": 1 (normalised time)
>>> "Trygve's code": 6.5
>>> "High level code": 30.6 (or 4.7 times slower than Trygve's)
>>>
>>> Here's the "High level code".
>>> ^(aString allSatisfy: [:each | each isSpace or: [each isDigit]])
>> and: [
>>> |digitsReverse|
>>> digitsReverse := (aString select: [:each | each isDigit])
>> reverse.
>>> digitsReverse size > 1 and: [
>>> |evens odds evenSum oddSum|
>>> odds := digitsReverse withIndexSelect: [:y :i | i odd].
>>> evens := digitsReverse withIndexSelect: [:x :i | i even].
>>> oddSum := odds detectSum: [:y | y digitValue].
>>> evenSum := evens detectSum: [:x |
>>> #(0 2 4 6 8 1 3 5 7 9) at: x digitValue + 1].
>>> (oddSum + evenSum) \\ 10 = 0]]
>>>
>>> This is the kind of code I was recommending that Roelof write.
>>>
>>> As a rough guide, by counting traversals (including ones inside
>> existing
>>> methods), I'd expect the "high level" code to be at least 10 times
>> slower
>>> than the "no added slowness" code.
>>>
>>> We are in vehement agreement that there is a time to write high level
>>> really obvious easily testable and debuggable code, and that's most
>>> of the time, especially with programming exercises.
>>>
>>> I hope that we are also in agreement that factors of 30 (or even 6)
>>> *can* be a serious problem. I mean, if I wanted something that slow,
>>> I'd use Ruby.
>>>
>>> I hope we are also agreed that (with the exception of investigations
>>> like this one) the time to hack on something to make it faster is
>> AFTER
>>> you have profiled it and determined that you have a problem.
>>>
>>> But I respectfully suggest that there is a difference taking slowness
>> OUT
>>> and simply not going out of your way to add slowness in the first
>> place.
>>>
>>> I'd also like to remark that my preference for methods that traverse
>> a
>>> sequence exactly once has more to do with Smalltalk protocols than
>>> with efficiency. If the only method I perform on an object is #do:
>>> the method will work just as well for readable streams as for
>>> collections. If the only method I perform on an object is
>> #reverseDo:
>>> the method will work just as well for Read[Write]Streams as for
>>> SequenceReadableCollections, at least in my library. It's just like
>>> trying to write #mean so that it works for Durations as well as
>> Numbers.
>>>
>>> Oh heck, I suppose I should point out that much of the overheads in
>>> this case could be eliminated by a Self-style compiler doing dynamic
>>> inlining + loop fusion. There's no reason *in principle*, given
>> enough
>>> people, money, and time, that the differences couldn't be greatly
>>> reduced in Pharo.
>>>
>>> On Tue, 5 May 2020 at 21:50, Trygve Reenskaug <trygver(a)ifi.uio.no>
>> wrote:
>>>
>>>
>>> Richard,
>>>
>>> Thank you for looking at the code. It is comforting to learn that the
>> code has been executed for a large number of examples without breaking.
>> The code is not primarily written for execution but for being read and
>> checked by the human end user. It would be nice if we could also check
>> that it gave the right answers, but I don't know how to do that.
>>>
>>> The first question is: Can a human domain expert read the code and
>> sign their name for its correctness?
>>>
>>>
>>> When this is achieved, a programming expert will transcribe the first
>> code to a professional quality program. This time, the second code
>> should be reviewed by an independent programmer who signs their name
>> for its correct transcription from the first version.
>>>
>>> --Trygve
>>>
>>> PS: In his 1991 Turing Award Lecture, Tony Hoare said: "There are two
>> ways of constructing a software design: One way is to make it so simple
>> that there are obviously no deficiencies and the other is to make it so
>> complicated that there are no obvious deficiencies. The first method is
>> far more difficult."
>>>
>>> --Trygve
>>>
>>> On tirsdag.05.05.2020 04:41, Richard O'Keefe wrote:
>>>
>>> As a coding experiment, I adapted Trygve Reenskoug's code to my
>>> Smalltalk compiler, put in my code slightly tweaked, and benchmarked
>>> them on randomly generated data.
>>>
>>> Result: a factor of 6.3.
>>>
>>> In Squeak it was a factor of ten.
>>>
>>> I had not, in all honesty, expected it to to be so high.
>>>
>>> On Tue, 5 May 2020 at 02:00, Trygve Reenskaug <trygver(a)ifi.uio.no>
>> wrote:
>>>
>>> A coding experiment.
>>> Consider a Scrum development environment. Every programming team has
>> an end user as a member.
>>> The team's task is to code a credit card validity check.
>>> A first goal is that the user representative shall read the code and
>> agree that it is a correct rendering of their code checker:
>>>
>>> luhnTest: trialNumber
>>> | s1 odd s2 even charValue reverse |
>>> -----------------------------------------------
>>> " Luhn test according to Rosetta"
>>> "Reverse the order of the digits in the number."
>>> reverse := trialNumber reversed.
>>> "Take the first, third, ... and every other odd digit in the reversed
>> digits and sum them to form the partial sum s1"
>>> s1 := 0.
>>> odd := true.
>>> reverse do:
>>> [:char |
>>> odd
>>> ifTrue: [
>>> s1 := s1 + char digitValue.
>>> ].
>>> odd := odd not
>>> ].
>>> "Taking the second, fourth ... and every other even digit in the
>> reversed digits:
>>> Multiply each digit by two and sum the digits if the answer is
>> greater than nine to form partial sums for the even digits"
>>> "The subtracting 9 gives the same answer. "
>>> "Sum the partial sums of the even digits to form s2"
>>> s2 := 0.
>>> even := false.
>>> reverse do:
>>> [:char |
>>> even
>>> ifTrue: [
>>> charValue := char digitValue * 2.
>>> charValue > 9 ifTrue: [charValue := charValue -
>> 9].
>>> s2 := s2 + charValue
>>> ].
>>> even := even not
>>> ].
>>> "If s1 + s2 ends in zero then the original number is in the form of a
>> valid credit card number as verified by the Luhn test."
>>> ^(s1 + s2) asString last = $0
>>> ---------------------------------
>>> Once this step is completed, the next step will be to make the code
>> right without altering the algorithm (refactoring). The result should
>> be readable and follow the team's conventions.
>>>
>>>
>>> P.S. code attached.
>>>
>>>
>>> --
>>>
>>> The essence of object orientation is that objects collaborate to
>> achieve a goal.
>>> Trygve Reenskaug mailto: trygver(a)ifi.uio.no
>>> Morgedalsvn. 5A http://folk.uio.no/trygver/
>>> N-0378 Oslo http://fullOO.info
>>> Norway Tel: (+47) 468 58 625
>>>
>>>
>>>
>>> --------------------------------------------
>>> Stéphane Ducasse
>>> http://stephane.ducasse.free.fr / http://www.pharo.org
>>> 03 59 35 87 52
>>> Assistant: Julie Jonas
>>> FAX 03 59 57 78 50
>>> TEL 03 59 35 86 16
>>> S. Ducasse - Inria
>>> 40, avenue Halley,
>>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>>> Villeneuve d'Ascq 59650
>>> France
>>>
>
--------------------------------------------
Stéphane Ducasse
http://stephane.ducasse.free.fr / http://www.pharo.org
03 59 35 87 52
Assistant: Julie Jonas
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France
May 14, 2020