- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo on a Netbook running TinyCore Linux

by StÃ©phane Ducasse

I love it. Now imagine with our specialised kernel or shrunk down versionâ¦ We are preparing to - remove a lot of code from Pharo 90 (spec1, eye inspector, GT, Glamourâ¦.) - but also to give the possibility to load on demand projects that we are integrating and TESTING - Microdown - Roassal 30. S > On 8 Sep 2020, at 03:22, tbrunz <wild.ideas(a)gmail.com> wrote: > > This is running 32-bit Pharo 80 on 32-bit TinyCore 11.1 (Linux kernel 5.4.3). > > There is a 64-bit version of TinyCore, which I plan to test next... > Then test 64-bit Pharo 80 and try Pharo Launcher on top of that. > Then on a Raspberry Pi... > > Here's what's intriguing about this: > > TinyCore Linux is SUPER tiny -- 11MB for the headless 'Core' version, and > 16MB for a FLTK/FLWM desktop. (Many different desktops are available.) The > 'CorePlus' version (which I'm booted on) is still only 106MB; it supports > Wifi & comes with installation tools & a variety of DEs to pick from. > > With TinyCore, you "build it the way you like it", by adding just the > packages you want in your Linux image. With a stripped-down implementation, > it's around the same size as the Pharo VM! > > Which makes TinyCore basically "a snap-on HAL module for the Pharo VM" that > gives you what amounts to bare-metal operation -- and it can run 100% from > RAM (as well as via mounting packages from persistent storage, on a > package-by-package basis). > > You can persist TinyCore on disk, and keep your installed packages ("tce > extensions") and your settings & user files persisted separately. That > helps keep the TinyCore OS from being corrupted -- it's much like the > '.image' file for Pharo; your changes are kept in a separate file. > > This opens up the possibility of making tiny/embedded little "appliances" > that boot into TC, then auto-launch a Pharo image -- headless or with a UI, > all without the burden of launching/maintaining full OS to do so. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle 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

Sept. 8, 2020

Re: [Pharo-users] Can it do this way ?

by Steffen MÃ¤rcker

Hi Richard and Roelof, thanks for your comprehensive answer. I brought up Regex only to point out alternative solutions. Another one is the following using transducers, where Tee works like the tee command from the command line. IsbnValidator>>isValidIsbn: aString | length countChars separators getSeparators lastChar getLastChar filterDigits computeCheckSum checkSum | "Count number of characters" length := 0. countChars := [:count :char | length := length + 1] init: length. "Get non-digit characters" separators := Set new getSeparators := separators <~ #isDigit remove. "Get last character" lastChar := nil. getLastChar := [:prev :char | lastChar := char ] init: lastChar. "Get digits" filterDigits := #isDigit filter. "Calculate check sum" computeCheckSum := ([:sum :index :digit | sum + index * digit value] init: 0) completing: #\\ . "Compute" checkSum := aString transduce: (Tee to: countChars) * (Tee to: getSeparators) * (Tee to: getLastChar) * filterDigits reduce: computeCheckSum init: 0. "Check validity" ^((length = 10 or: [length = 13]) and: [separators = Set with: $-]) and: [checkSum = (lastChar = $X ifTrue: [10] ifFalse: [lastChar value])] Kind regards, Steffen Am .09.2020, 08:30 Uhr, schrieb Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org>: > Op 8-9-2020 om 04:22 schreef Richard O'Keefe: >> There are two quite different questions. >> (1) Where may dashes occur in a real ISBN-10? >> (2) What does Exercism require in the specification and check in the >> test cases? >> >> For (1) the rules are >> >> Each ISBN consists of 5 elements with each section being separated by >> spaces or hyphens. Three of the five elements may be of >>varying >> length: >> Prefix element â currently this can only be either 978 or 979. It is >> always 3 digits in lengthRegistration group element â this identifies >> the particular country, geographical region, or language area >> participating >>in the ISBN system. This element may be between 1 and 5 >> digits in lengthRegistrant element - this identifies the particular >> publisher or imprint. This may be up to 7 digits in lengthPublication >> element â this identifies the particular edition and format of a >> specific title. This may be up to 6 digits >>in lengthCheck digit â >> this is always the final single digit that mathematically validates the >> rest of the number. It is >>calculated using a Modulus 10 system with >> alternate weights of 1 and 3.An ISBN-10 does not have the three-digit >> prefix. So we have >> [0-9]{1,5} -- prefix >> [0-9]{1,7} -- registrant >> [0-9]{1,6} -- publication >> [0-9X] >> -- check digit >> >> As an examplw, "Standard C++ IOStreams and Locales" by Langer & Kreft >> has >> ISBN-10 0-201-18395-1 >> ISBN-13 9780201183955 >> so I shall assume the separators are optional. >> /^[0-9]{1,5}[- ]?[0-9]{1,7}[- ]?[0-9]{1,6}[- ]?[0-9X]$/ >> Of course the elements cannot all have their maximum length at the same >> time. In AWK I would write >> x = a_putative_ISBN_10 >> y = x >> gsub(/[- ]+/, "", y) >> if (x ~ /^[0-9]{1,5}[- ]?[0-9]{1,7}[- ]?[0-9]{1,6}[- ]?[0-9X]$/ \ >> && y ~ /^[0-9]{9,9}[0-9X]$/ \ >> ) { >> x *might* be valid, we still need to check the checksum >> } >> >> For (2), there appear to be no restrictions on where dashes may occur >> or how many: "These may be communicated with or without hyphens". >> Exercism doesn't allow spaces. >> >> Regular expressions are elegant in their own way, BUT for this problem >> they are (a) excessive, (b) inefficient, and (c) insufficient. >> >> digit count := 0. >> check sum := 0. >> for each character c of the string >> if c is not a hyphen then >> if c is a digit then >> digit value := c's value as a digit >> else if c is X and digit count = 9 then >> digit value := 10 >> else >> return false. >> digit count := digit count + 1. >> if digit count > 10 then return false. >> check sum := (11 - digit count) * digit value + check sum. >> return check sum mod 11 is zero. >> >> Part of the insight here is "don't DO it, just PRETEND you did." >> That is, instead of copying the string without the hyphens, >> just ignore the hyphens as they turn up. >> Another part is "if you are only going to use it once, don't store it." >> That is, we need a digit's value just once, in the update to check sum, >> so we should compute it just before we need it, not store it. >> >> Now the pseudo-code above is classic sequential imperative coding. >> >> Classic functional coding does something like >> let no_dashes = filter (/= '-') (explode string) in >> length no_dashes = 10 and >> let check = last no_dashes in >> (is_digit check or check = 'X') and >> all is_digit (take 9 no_dashes) and >> let xval c = if x = 'X' then 10 else digit_value c in >> dot (map xval no_dashes) [10,9..1]) mod 11 = 0 >> >> This pseudo-code translates nicely to Smalltalk too. >> You might want to add >> >> SequenceableCollection>> >> with: other inject: initial into: aBlock >> |r| >> r := initial. >> self with: other do: [:x :y | >> r := aBlock value: r value: x value: y]. >> ^r >> dot: other >> ^self with: other inject: 0 into: [:acc :x :y | x*y + acc] >> >> (These methods are so obvious that it would be absurd to claim >> any intellectual property rights to them.) >> >> I also have "fusion" methods like >> SequenceableCollection>> >> from: start to: finish allSatisfy: testBlock >> self from: start to: finish do: [:each | >> (aBlock value: each) ifFalse: [^false]]. >> ^true >> >> so that ((seq copyFrom: a to: z) allSatisfy: blk) >> can be done as (seq from: a to: z allSatisfy: blk) >> without making a copy. >> >> Fusion methods are useful because Smalltall compilers >> don't work as hard at eliminating intermediate data >> structures as functional language compilers. (Having >> other priorities.) >> >> (isdigit (last no_dashes return false if digit count > 10. >> > > > Thanks for letting me see this.But still I wonder if this is really the > OOP way and if that function does more then 1 thing.It looks to me that > its iterating trrough the string. Calculating the crc and checking it.I > learned that it is a good thing that a function and a class does only 1 > thing. > Roelof

Sept. 8, 2020

Re: [Pharo-users] Pharo on a Netbook running TinyCore Linux

by tbrunz

...and 64-bit Pharo runs in 64-bit TinyCore. So does Pharo Launcher. However, I kept getting bit by the "External module not found" error (libgit2). . <http://forum.world.st/file/t372161/Pharo8-64_TinyCore_AcerD255_2020-0907a.j…> . <http://forum.world.st/file/t372161/Pharo8-64_TinyCore_AcerD255_2020-0907b.j…> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 8, 2020

Re: [Pharo-users] Can it do this way ?

by Roelof Wobben

Sept. 8, 2020

Re: [Pharo-users] Rounding in Floats

by Esteban Maringolo

On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <raoknz(a)gmail.com> wrote: > > "7.1 roundTo: 0.1 should return 7.1" > You're still not getting it. I was until Konrad explained it. > Binary floating point CANNOT represent either of those numbers. > You seem to be assuming that Pharo is making some mistake. > It isn't. All it is doing is refusing to lie to you. <snip> > The systems that print 7.1 are LYING to you, > and Pharo is not. I'm not assuming a mistake from Pharo, I had a wrong expectation what to get if I round to that precision. I don't know whether other systems lie or simply fulfill user expectations, if you send the #roundTo: to a float, I did expect to get a number with the same precision. That is my expectation as a user. As in the other thread I expected two scaled decimals that are printed equal to also be compared as equal (which they don't). Whether there is a good reason for those behaviors is beyond my current comprehension, but it certainly doesn't follow the "principle of least surprise". In any case, the method proposed by Tomohiro solved my issues. Regards, Esteban A. Maringolo

Sept. 8, 2020

Re: [Pharo-users] Rounding in Floats

by Richard O'Keefe

"7.1 roundTo: 0.1 should return 7.1" You're still not getting it. 7.1 IS NOT 71/10. 0.1 IS NOT 1/10. Binary floating point CANNOT represent either of those numbers. You seem to be assuming that Pharo is making some mistake. It isn't. All it is doing is refusing to lie to you. #include <math.h> #include <stdio.h> int main(void) { printf("%.18f\n", 7.1); printf("%.18f\n", round(7.1 / 0.1) * 0.1); return 0; } % a.out 7.099999999999999645 7.100000000000000533 Does this help? "7.1" is a bit LESS than 7.1. "7.1 roundTo: 0.1" is a bit MORE than 7.1. This is the best that the computer's hardware can do. The systems that print 7.1 are LYING to you, and Pharo is not. On Tue, 8 Sep 2020 at 00:28, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > Hi Sven, > > On Mon, Sep 7, 2020 at 9:10 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 6 Sep 2020, at 22:21, Esteban Maringolo <emaringolo(a)gmail.com> > wrote: > > > > > > It is not for printing but for testing. I want to assert that a > > > certain calculation gives the expected result. > > > > Then you should use #assert:closeTo: and friends. > > (9.1 + (-2.0)) closeTo: 7.1 precision: 0.1. > > I remembered about it, and implemented my own > #assertDifferential:equals: which I first did convert to > ScaledDecimals and then compares with #roundedByScale. > > > Floats should always be compared using an epsilon (precision) value in > tests, not using equality. > > Sure, but 7.1 roundTo: 0.1 should return 7.1. Shouldn't it? > > Regards! > > Esteban A. Maringolo > >

Sept. 8, 2020

Re: [Pharo-users] Can it do this way ?

by Richard O'Keefe

There are two quite different questions. (1) Where may dashes occur in a real ISBN-10? (2) What does Exercism require in the specification and check in the test cases? For (1) the rules are Each ISBN consists of 5 elements with each section being separated by spaces or hyphens. Three of the five elements may be of varying length: - *Prefix element* â currently this can only be either 978 or 979. It is always 3 digits in length - *Registration group element* â this identifies the particular country, geographical region, or language area participating in the ISBN system. This element may be between 1 and 5 digits in length - *Registrant element* - this identifies the particular publisher or imprint. This may be up to 7 digits in length - *Publication element* â this identifies the particular edition and format of a specific title. This may be up to 6 digits in length - *Check digit* â this is always the final single digit that mathematically validates the rest of the number. It is calculated using a Modulus 10 system with alternate weights of 1 and 3. An ISBN-10 does not have the three-digit prefix. So we have [0-9]{1,5} -- prefix [0-9]{1,7} -- registrant [0-9]{1,6} -- publication [0-9X] -- check digit As an examplw, "Standard C++ IOStreams and Locales" by Langer & Kreft has ISBN-10 0-201-18395-1 ISBN-13 9780201183955 so I shall assume the separators are optional. /^[0-9]{1,5}[- ]?[0-9]{1,7}[- ]?[0-9]{1,6}[- ]?[0-9X]$/ Of course the elements cannot all have their maximum length at the same time. In AWK I would write x = a_putative_ISBN_10 y = x gsub(/[- ]+/, "", y) if (x ~ /^[0-9]{1,5}[- ]?[0-9]{1,7}[- ]?[0-9]{1,6}[- ]?[0-9X]$/ \ && y ~ /^[0-9]{9,9}[0-9X]$/ \ ) { x *might* be valid, we still need to check the checksum } For (2), there appear to be no restrictions on where dashes may occur or how many: "These may be communicated with or without hyphens". Exercism doesn't allow spaces. Regular expressions are elegant in their own way, BUT for this problem they are (a) excessive, (b) inefficient, and (c) insufficient. digit count := 0. check sum := 0. for each character c of the string if c is not a hyphen then if c is a digit then digit value := c's value as a digit else if c is X and digit count = 9 then digit value := 10 else return false. digit count := digit count + 1. if digit count > 10 then return false. check sum := (11 - digit count) * digit value + check sum. return check sum mod 11 is zero. Part of the insight here is "don't DO it, just PRETEND you did." That is, instead of copying the string without the hyphens, just ignore the hyphens as they turn up. Another part is "if you are only going to use it once, don't store it." That is, we need a digit's value just once, in the update to check sum, so we should compute it just before we need it, not store it. Now the pseudo-code above is classic sequential imperative coding. Classic functional coding does something like let no_dashes = filter (/= '-') (explode string) in length no_dashes = 10 and let check = last no_dashes in (is_digit check or check = 'X') and all is_digit (take 9 no_dashes) and let xval c = if x = 'X' then 10 else digit_value c in dot (map xval no_dashes) [10,9..1]) mod 11 = 0 This pseudo-code translates nicely to Smalltalk too. You might want to add SequenceableCollection>> with: other inject: initial into: aBlock |r| r := initial. self with: other do: [:x :y | r := aBlock value: r value: x value: y]. ^r dot: other ^self with: other inject: 0 into: [:acc :x :y | x*y + acc] (These methods are so obvious that it would be absurd to claim any intellectual property rights to them.) I also have "fusion" methods like SequenceableCollection>> from: start to: finish allSatisfy: testBlock self from: start to: finish do: [:each | (aBlock value: each) ifFalse: [^false]]. ^true so that ((seq copyFrom: a to: z) allSatisfy: blk) can be done as (seq from: a to: z allSatisfy: blk) without making a copy. Fusion methods are useful because Smalltall compilers don't work as hard at eliminating intermediate data structures as functional language compilers. (Having other priorities.) (isdigit (last no_dashes return false if digit count > 10. On Tue, 8 Sep 2020 at 03:02, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > No problem. I am not knowledgeable about isbn numbers. At which places may > a dash occur? > > Kind regards, > Steffen > > 07.09.2020 16:18:22 Roelof Wobben via Pharo-users < > pharo-users(a)lists.pharo.org>: > > > Op 6-9-2020 om 10:07 schreef Steffen MÃ¤rcker: > >> Maybe this is a naive question, but can you just split the task into the > >> following two? > >> > >> 1. Check whether whether the string is syntactically an ISBN number. > >> This can be done, e.g., using a regex. > >> > >> 2. Check the the check character. > >> Calculate the check character from the (now to be known) syntactically > >> valid string. > >> > >> ISBNValidator>>isValidISBN: aString > >> ^(self isSyntacticallyValid: aString) and: [self isCheckCharacterValid: > >> aString] > >> > >> Kind regards, > >> Steffen nder if the code will not be too big. I learned that it is good > >> > > Sorry to respond not earlier but your respons seems to be in the spam > folder of my provider. > > > > I could do that but if very bad in regex so I do not know a regex which > van validate 123456789 or 123-456-78-9 > > > > Roelof > > > >

Sept. 8, 2020

Re: [Pharo-users] Pharo on a Netbook running TinyCore Linux

by tbrunz

BTW, TinyCore Linux was started by Robert Shingledecker. He's the guy who led the "Damn Small Linux" project[1]; when it dissolved, he started TinyCore and kept going... [1] http://www.damnsmalllinux.org/ -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 8, 2020

Re: [Pharo-users] Pharo on a Netbook running TinyCore Linux

by tbrunz

This is running 32-bit Pharo 80 on 32-bit TinyCore 11.1 (Linux kernel 5.4.3). There is a 64-bit version of TinyCore, which I plan to test next... Then test 64-bit Pharo 80 and try Pharo Launcher on top of that. Then on a Raspberry Pi... Here's what's intriguing about this: TinyCore Linux is SUPER tiny -- 11MB for the headless 'Core' version, and 16MB for a FLTK/FLWM desktop. (Many different desktops are available.) The 'CorePlus' version (which I'm booted on) is still only 106MB; it supports Wifi & comes with installation tools & a variety of DEs to pick from. With TinyCore, you "build it the way you like it", by adding just the packages you want in your Linux image. With a stripped-down implementation, it's around the same size as the Pharo VM! Which makes TinyCore basically "a snap-on HAL module for the Pharo VM" that gives you what amounts to bare-metal operation -- and it can run 100% from RAM (as well as via mounting packages from persistent storage, on a package-by-package basis). You can persist TinyCore on disk, and keep your installed packages ("tce extensions") and your settings & user files persisted separately. That helps keep the TinyCore OS from being corrupted -- it's much like the '.image' file for Pharo; your changes are kept in a separate file. This opens up the possibility of making tiny/embedded little "appliances" that boot into TC, then auto-launch a Pharo image -- headless or with a UI, all without the burden of launching/maintaining full OS to do so. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 8, 2020

Re: [Pharo-users] Pharo on a Netbook running TinyCore Linux

by tbrunz

Just to be sure I'm not booted into Ubuntu: <http://forum.world.st/file/t372161/Pharo8-32_TinyCore_AcerD255_2020-0907b.j…> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 8, 2020