Re: [Pharo-users] mentor question 4
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 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 wrote: > > > > On May 11, 2020 2:19:49 PM PDT, Richard O'Keefe 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 > wrote: > > > > > On 5 May 2020, at 16:16, Richard O'Keefe 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 g
Re: [Pharo-users] Need help putting my Pharo package under source control
Also, regarding keeping your images under control, if you haven't downloaded and started using Pharo Launcher, you should! It's a fabulous tool... http://pharo.org/download -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Re: [Pharo-users] Need help putting my Pharo package under source control
Hi, Your document is definitely out of date! The current version of PBE for version 5, 6, and 7 can be found here: https://github.com/SquareBracketAssociates/UpdatedPharoByExample/releases If you're using Pharo 8 or 9, you'll want the updated version, PBE8, which can be found here: https://github.com/SquareBracketAssociates/PharoByExample80/releases Yes, you can FileOut and FileIn. If you right-click on an item in the System Browser (which was 'Nautilus' until version 7, when it was replaced with 'Calypso'), the last fly-out menu has 'FileOut' listed. (I think you need to send a message in the Playground to use 'FileIn'; I'm not sure, as, like most, I don't use it.) Note that you can no longer (or "shouldn't") use SmalltalkHub; it's deprecated, and if it's not already locked for modifications, it will be shortly. (Then it becomes read-only until late in the year, when the site will be shut down.) So you *should* use GitHub. Since version 7, it's the default repository for Pharo code. There is now a native Git client in Pharo called "Iceberg". It works with GitHub, GitLab, BitBucket, local git repos, and remote git repos. You can create git repos, commit/push/pull, submit PRs, etc. from Iceberg while remaining in the Pharo IDE. You can read more about Iceberg and managing code here: https://github.com/SquareBracketAssociates/Booklet-ManagingCode/releases Have fun! -Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Re: [Pharo-users] mentor question 4
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 wrote: > > > > On May 11, 2020 2:19:49 PM PDT, Richard O'Keefe 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 >> wrote: >>> >>> >>> >>> On 5 May 2020, at 16:16, Richard O'Keefe 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 >> 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 b
Re: [Pharo-users] mentor question 4
On May 11, 2020 2:19:49 PM PDT, Richard O'Keefe 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 > wrote: >> >> >> >> On 5 May 2020, at 16:16, Richard O'Keefe 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 >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 m
Re: [Pharo-users] mentor question 4
I was saying that I expected #($a $b $c) asString ==> 'abc'. 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 wrote: > > > > On 5 May 2020, at 16:16, Richard O'Keefe 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 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
[Pharo-users] Need help putting my Pharo package under source control
--- Begin Message --- I read the section in 2018-09-29-UPDATEDPHAROBYEXAMPLE: "Monticello packages” just after Figure 3-27 I have a smalltalkhub account and created a repository: MCHttpRepository location: 'http://smalltalkhub.com/mc/MichaelKentBurns/FredsLunch/main' user: '' password: ‘' In Pharo I registered this as a new smalltalkhub repository: 'http://smalltalkhub.com/mc/MichaelKentBurns/FredsLunch/main’ And it shows up in the repository list for my package. Then I think I’m supposed to poke ‘Save’. It was kind of sketchy and popped up exception dialogs while I was typing my comment, but eventually it worked. I was able to download the resultant .mcz file and unzip it, then change the ^M to newlines to get a readable source. I’m not really happy about this process. I would like to actually save this into my GitHub repository. The document mentioned at the top mentions using git, but just says: There is a chapter in preparation on how to use Git with Pharo. Request it on the Pharo mailing list. Question 1: Is there such a document? If so, can you point me to it? Question 2: Is there a way to fileOut a class, or a package? --- End Message ---
Re: [Pharo-users] mentor question 4
> 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 The asString looks wrong to me. I will report it as a bug. Now in Pharo we should really introduce display string > #($a $b $c) > > Does anyone here know WHY Squeak and Pharo do what they do here? > > On Wed, 6 May 2020 at 01:20, Richard O'Keefe 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 differen
Re: [Pharo-users] [ANN] Pharo Compendium
In the past we added metadata to manifest. And the compedium could take advantage of that. We will have to work on it (end of the month). S > On 4 May 2020, at 01:33, Torsten Bergmann wrote: > > Yes - I was developing on P9 and never tried it in Pharo 8. But I checked now > - seems to work without > any problem there as well. > > Thx > T. > > > Gesendet: Sonntag, 03. Mai 2020 um 22:36 Uhr > Von: "Stéphane Ducasse" > An: "Any question about pharo is welcome" > Betreff: Re: [Pharo-users] [ANN] Pharo Compendium > > It can probably work in P8 because parts of Spec20 are working in P8 but not > all the features and widgets like tables and others. > But torsten will tell us. > > On 3 May 2020, at 17:34, Esteban Maringolo > mailto:emaring...@gmail.com]> wrote: > > Excellent Torsten! > > I guess it will not work in Pharo 8 because of the Spec 2 requirement. Right? > > Regards! > > Esteban A. Maringolo > > 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
