January 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] why is my css not found in a seaside project

by Roelof Wobben

I think I found the answer myself when I put this in the RootComponent updateRoot: anHtmlRoot Â Â Â super updateRoot: anHtmlRoot. Â Â Â anHtmlRoot stylesheet url: (PaintingLibraryÂ urlOf: #mainCss) and this on the class side of the RootComponent initialize Â Â Â | app | Â Â Â app := WAAdmin Â Â Â Â Â Â register: #stRootComponent Â Â Â Â Â Â asApplicationAt: 'Paintings2'. Â Â Â app addLibrary: PaintingLibrary then I see some css. The page looks not what I expect but that can be changed. So does the code I have now on my github page well or do I use the components still the wrong way ? Roelof Op 5-1-2020 om 12:48 schreef Roelof Wobben: > Op 5-1-2020 om 11:36 schreef Roelof Wobben via Pharo-users: > > hmm, > > It looks like I had to do it like this : > https://github.com/RoelofWobben/paintings > for registering the project but I see then that the rootcomponent is > not changed and that still the css is not found or used. > > > So please help. > > Roelof >

Jan. 5, 2020

Re: [Pharo-users] can I make this so the vm would not be not responsibe when running the tests

by Roelof Wobben

There you are right but the hint we get was thinking about recursion but your lessons showed me other ways to do it which I think are more the way smalltalk works, Thanks for that. Roelof Op 5-1-2020 om 14:24 schreef Richard O'Keefe: > I did not ask why you were validating input. > I asked about why you *repeatedly* validated input. > > Think of it this way: > publicMethod: arg1 also: arg2 > ... check arg1 ... > ... check arg2 ... > ^self privateMethod: arg1 also: arg2 > > privateMethod: arg1 also: arg2 > ... trust that arg1 and arg2 are valide ... > ... recursive calls use #privateMethod:andAlso: ... > ... not #publicMethod:andAlso: and must ensure ... > ... that arguments are valid by construction ... > > In my solution to the "Grains" exercism, I have > atSquare: n -- checks its argument > total ^(1 bitShift: 64) - 1 > You are required to implement these two methods, true. > You are NOT required to implement #total by calling #atSquare:. > Not even once. Nor is #atSquare: required to be recursive. > > On Mon, 6 Jan 2020 at 02:05, Roelof Wobben <r.wobben(a)home.nl> wrote: >> Hello Ricard. >> >> You mean when I calcualate the total of a board. >> That is because on when I had to calculate the number of a particular >> field there were tests where the number was lower then zero or higher >> then 64 which makes no sense. >> >> But im open for a solution where on a particular field I could check for >> that and for the total I do not need that part. >> >> Roelof >> >> >> >> Op 5-1-2020 om 13:58 schreef Richard O'Keefe: >>> Time microsecondsToRun: [ >>> |n| >>> n := (2 raisedToInteger: 8 * 8) - 1. >>> Transcript >>> nextPutAll: 'The number of grains on an 8x8 chessboard is '; >>> print: n; cr; endEntry]. >>> <PRINT-IT> >>> On my laptop, this reports 194 microseconds. >>> >>> Why would you use recursion, anyway? >>> >>> Time microsecondsToRun: [ >>> |n| >>> n := (1 to: 8 * 8) inject: 0 into: [:acc :each | acc+acc+1]. >>> Transcript >>> nextPutAll: 'The number of grains on an 8x8 chessboard is '; >>> print: n; cr; endEntry]. >>> <PRINT-IT> >>> On the same laptop, this reports 118 microseconds. >>> >>> One of the lessons of 'functional' languages, promptly adopted by Smalltalk, is >>> to encapsulate control structures into reusable methods, such as #inject:into:, >>> more commonly known as `foldl` in functional languages. It's then none of >>> my business whether such a method works by recursion, iteration, or gangs >>> of otherwise seasonally unemployed Christmas elves. >>> >>> In my own Smalltalk library, >>> (GeometricSeries new: 64 from: 1 byFactor: 2) sum >>> only takes 15 microseconds. >>> >>> I do note that you are calling validateInput repeatedly. Why? >>> >>> >>> On Sun, 5 Jan 2020 at 07:41, Roelof Wobben via Pharo-users >>> <pharo-users(a)lists.pharo.org> wrote: >>>> Oke, >>>> >>>> So I can better not use recursion for this problem if I understand you well, Richard. >>>> >>>> Roelof >>>> >>>> >>>> >>>> Op 4-1-2020 om 19:02 schreef Richard Sargent: >>>> >>>> On Sat, Jan 4, 2020 at 9:47 AM Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >>>>> Hello, >>>>> >>>>> For a exercism challenge I need to calculate the total grains on a >>>>> chessboard. >>>>> So I did : >>>>> >>>>> atSquare: anInteger >>>>> self validateInput: anInteger. >>>>> ^ anInteger = 1 >>>>> ifTrue: [ 1 ] >>>>> ifFalse: [ 2 * (self atSquare: anInteger - 1) ] >>>>> >>>>> >>>>> but when I run the tests , the vm seems to be not responsive for some 4 >>>>> - 5 seconds. >>>>> >>>>> Is there a way I can use this code and take care that the vm stays >>>>> responsive. >>>> What do you want the VM to do in addition to calculating that sum while it is calculating that sum? >>>> >>>> >>>> The best way to keep the VM responsive is to take a page from Gauss' notebook and pay attention to the numbers[1]. Let's consider the first four squares and extrapolate from there. >>>> >>>> In binary, the squares hold the following grains: 2r1, 2r10, r2100, and 2r1000. When we add them up, we get 2r1111. If we use Gauss' tricks, we can notice that 2r1111 is equal to 2r10000 - 1. So, the sum of the grains on the first 4 squares is 2^5 - 1. You can easily generalize that pattern, of course. Then your program can calculate the answer quickly. >>>> >>>> >>>> [1] The story goes that Gauss' teacher was frustrated with his student's abilities and set him a challenge to occupy him for some time: sum the numbers from 1 through 100. Gauss immediately answered 5,050, much to his teacher's chagrin. >>>> >>>>> Regards, >>>>> >>>>> Roelof >>>>> >>>>>

Jan. 5, 2020

Re: [Pharo-users] can I make this so the vm would not be not responsibe when running the tests

by Richard O'Keefe

I did not ask why you were validating input. I asked about why you *repeatedly* validated input. Think of it this way: publicMethod: arg1 also: arg2 ... check arg1 ... ... check arg2 ... ^self privateMethod: arg1 also: arg2 privateMethod: arg1 also: arg2 ... trust that arg1 and arg2 are valide ... ... recursive calls use #privateMethod:andAlso: ... ... not #publicMethod:andAlso: and must ensure ... ... that arguments are valid by construction ... In my solution to the "Grains" exercism, I have atSquare: n -- checks its argument total ^(1 bitShift: 64) - 1 You are required to implement these two methods, true. You are NOT required to implement #total by calling #atSquare:. Not even once. Nor is #atSquare: required to be recursive. On Mon, 6 Jan 2020 at 02:05, Roelof Wobben <r.wobben(a)home.nl> wrote: > > Hello Ricard. > > You mean when I calcualate the total of a board. > That is because on when I had to calculate the number of a particular > field there were tests where the number was lower then zero or higher > then 64 which makes no sense. > > But im open for a solution where on a particular field I could check for > that and for the total I do not need that part. > > Roelof > > > > Op 5-1-2020 om 13:58 schreef Richard O'Keefe: > > Time microsecondsToRun: [ > > |n| > > n := (2 raisedToInteger: 8 * 8) - 1. > > Transcript > > nextPutAll: 'The number of grains on an 8x8 chessboard is '; > > print: n; cr; endEntry]. > > <PRINT-IT> > > On my laptop, this reports 194 microseconds. > > > > Why would you use recursion, anyway? > > > > Time microsecondsToRun: [ > > |n| > > n := (1 to: 8 * 8) inject: 0 into: [:acc :each | acc+acc+1]. > > Transcript > > nextPutAll: 'The number of grains on an 8x8 chessboard is '; > > print: n; cr; endEntry]. > > <PRINT-IT> > > On the same laptop, this reports 118 microseconds. > > > > One of the lessons of 'functional' languages, promptly adopted by Smalltalk, is > > to encapsulate control structures into reusable methods, such as #inject:into:, > > more commonly known as `foldl` in functional languages. It's then none of > > my business whether such a method works by recursion, iteration, or gangs > > of otherwise seasonally unemployed Christmas elves. > > > > In my own Smalltalk library, > > (GeometricSeries new: 64 from: 1 byFactor: 2) sum > > only takes 15 microseconds. > > > > I do note that you are calling validateInput repeatedly. Why? > > > > > > On Sun, 5 Jan 2020 at 07:41, Roelof Wobben via Pharo-users > > <pharo-users(a)lists.pharo.org> wrote: > >> Oke, > >> > >> So I can better not use recursion for this problem if I understand you well, Richard. > >> > >> Roelof > >> > >> > >> > >> Op 4-1-2020 om 19:02 schreef Richard Sargent: > >> > >> On Sat, Jan 4, 2020 at 9:47 AM Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > >>> Hello, > >>> > >>> For a exercism challenge I need to calculate the total grains on a > >>> chessboard. > >>> So I did : > >>> > >>> atSquare: anInteger > >>> self validateInput: anInteger. > >>> ^ anInteger = 1 > >>> ifTrue: [ 1 ] > >>> ifFalse: [ 2 * (self atSquare: anInteger - 1) ] > >>> > >>> > >>> but when I run the tests , the vm seems to be not responsive for some 4 > >>> - 5 seconds. > >>> > >>> Is there a way I can use this code and take care that the vm stays > >>> responsive. > >> > >> What do you want the VM to do in addition to calculating that sum while it is calculating that sum? > >> > >> > >> The best way to keep the VM responsive is to take a page from Gauss' notebook and pay attention to the numbers[1]. Let's consider the first four squares and extrapolate from there. > >> > >> In binary, the squares hold the following grains: 2r1, 2r10, r2100, and 2r1000. When we add them up, we get 2r1111. If we use Gauss' tricks, we can notice that 2r1111 is equal to 2r10000 - 1. So, the sum of the grains on the first 4 squares is 2^5 - 1. You can easily generalize that pattern, of course. Then your program can calculate the answer quickly. > >> > >> > >> [1] The story goes that Gauss' teacher was frustrated with his student's abilities and set him a challenge to occupy him for some time: sum the numbers from 1 through 100. Gauss immediately answered 5,050, much to his teacher's chagrin. > >> > >>> Regards, > >>> > >>> Roelof > >>> > >>> >

Jan. 5, 2020

Re: [Pharo-users] can I make this so the vm would not be not responsibe when running the tests

by Roelof Wobben

Hello Ricard. You mean when I calcualate the total of a board. That is because on when I had to calculate the number of a particular field there were tests where the number was lower then zero or higher then 64 which makes no sense. But im open for a solution where on a particular field I could check for that and for the total I do not need that part. Roelof Op 5-1-2020 om 13:58 schreef Richard O'Keefe: > Time microsecondsToRun: [ > |n| > n := (2 raisedToInteger: 8 * 8) - 1. > Transcript > nextPutAll: 'The number of grains on an 8x8 chessboard is '; > print: n; cr; endEntry]. > <PRINT-IT> > On my laptop, this reports 194 microseconds. > > Why would you use recursion, anyway? > > Time microsecondsToRun: [ > |n| > n := (1 to: 8 * 8) inject: 0 into: [:acc :each | acc+acc+1]. > Transcript > nextPutAll: 'The number of grains on an 8x8 chessboard is '; > print: n; cr; endEntry]. > <PRINT-IT> > On the same laptop, this reports 118 microseconds. > > One of the lessons of 'functional' languages, promptly adopted by Smalltalk, is > to encapsulate control structures into reusable methods, such as #inject:into:, > more commonly known as `foldl` in functional languages. It's then none of > my business whether such a method works by recursion, iteration, or gangs > of otherwise seasonally unemployed Christmas elves. > > In my own Smalltalk library, > (GeometricSeries new: 64 from: 1 byFactor: 2) sum > only takes 15 microseconds. > > I do note that you are calling validateInput repeatedly. Why? > > > On Sun, 5 Jan 2020 at 07:41, Roelof Wobben via Pharo-users > <pharo-users(a)lists.pharo.org> wrote: >> Oke, >> >> So I can better not use recursion for this problem if I understand you well, Richard. >> >> Roelof >> >> >> >> Op 4-1-2020 om 19:02 schreef Richard Sargent: >> >> On Sat, Jan 4, 2020 at 9:47 AM Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >>> Hello, >>> >>> For a exercism challenge I need to calculate the total grains on a >>> chessboard. >>> So I did : >>> >>> atSquare: anInteger >>> self validateInput: anInteger. >>> ^ anInteger = 1 >>> ifTrue: [ 1 ] >>> ifFalse: [ 2 * (self atSquare: anInteger - 1) ] >>> >>> >>> but when I run the tests , the vm seems to be not responsive for some 4 >>> - 5 seconds. >>> >>> Is there a way I can use this code and take care that the vm stays >>> responsive. >> >> What do you want the VM to do in addition to calculating that sum while it is calculating that sum? >> >> >> The best way to keep the VM responsive is to take a page from Gauss' notebook and pay attention to the numbers[1]. Let's consider the first four squares and extrapolate from there. >> >> In binary, the squares hold the following grains: 2r1, 2r10, r2100, and 2r1000. When we add them up, we get 2r1111. If we use Gauss' tricks, we can notice that 2r1111 is equal to 2r10000 - 1. So, the sum of the grains on the first 4 squares is 2^5 - 1. You can easily generalize that pattern, of course. Then your program can calculate the answer quickly. >> >> >> [1] The story goes that Gauss' teacher was frustrated with his student's abilities and set him a challenge to occupy him for some time: sum the numbers from 1 through 100. Gauss immediately answered 5,050, much to his teacher's chagrin. >> >>> Regards, >>> >>> Roelof >>> >>>

Jan. 5, 2020

Re: [Pharo-users] can I make this so the vm would not be not responsibe when running the tests

by Richard O'Keefe

Time microsecondsToRun: [ |n| n := (2 raisedToInteger: 8 * 8) - 1. Transcript nextPutAll: 'The number of grains on an 8x8 chessboard is '; print: n; cr; endEntry]. <PRINT-IT> On my laptop, this reports 194 microseconds. Why would you use recursion, anyway? Time microsecondsToRun: [ |n| n := (1 to: 8 * 8) inject: 0 into: [:acc :each | acc+acc+1]. Transcript nextPutAll: 'The number of grains on an 8x8 chessboard is '; print: n; cr; endEntry]. <PRINT-IT> On the same laptop, this reports 118 microseconds. One of the lessons of 'functional' languages, promptly adopted by Smalltalk, is to encapsulate control structures into reusable methods, such as #inject:into:, more commonly known as `foldl` in functional languages. It's then none of my business whether such a method works by recursion, iteration, or gangs of otherwise seasonally unemployed Christmas elves. In my own Smalltalk library, (GeometricSeries new: 64 from: 1 byFactor: 2) sum only takes 15 microseconds. I do note that you are calling validateInput repeatedly. Why? On Sun, 5 Jan 2020 at 07:41, Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > Oke, > > So I can better not use recursion for this problem if I understand you well, Richard. > > Roelof > > > > Op 4-1-2020 om 19:02 schreef Richard Sargent: > > On Sat, Jan 4, 2020 at 9:47 AM Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >> >> Hello, >> >> For a exercism challenge I need to calculate the total grains on a >> chessboard. >> So I did : >> >> atSquare: anInteger >> self validateInput: anInteger. >> ^ anInteger = 1 >> ifTrue: [ 1 ] >> ifFalse: [ 2 * (self atSquare: anInteger - 1) ] >> >> >> but when I run the tests , the vm seems to be not responsive for some 4 >> - 5 seconds. >> >> Is there a way I can use this code and take care that the vm stays >> responsive. > > > What do you want the VM to do in addition to calculating that sum while it is calculating that sum? > > > The best way to keep the VM responsive is to take a page from Gauss' notebook and pay attention to the numbers[1]. Let's consider the first four squares and extrapolate from there. > > In binary, the squares hold the following grains: 2r1, 2r10, r2100, and 2r1000. When we add them up, we get 2r1111. If we use Gauss' tricks, we can notice that 2r1111 is equal to 2r10000 - 1. So, the sum of the grains on the first 4 squares is 2^5 - 1. You can easily generalize that pattern, of course. Then your program can calculate the answer quickly. > > > [1] The story goes that Gauss' teacher was frustrated with his student's abilities and set him a challenge to occupy him for some time: sum the numbers from 1 through 100. Gauss immediately answered 5,050, much to his teacher's chagrin. > >> >> Regards, >> >> Roelof >> >> >

Jan. 5, 2020

Re: [Pharo-users] why is my css not found in a seaside project

by Roelof Wobben

Op 5-1-2020 om 11:36 schreef Roelof Wobben via Pharo-users: hmm, It looks like I had to do it like this : https://github.com/RoelofWobben/paintings for registering the project but I see then that the rootcomponent is not changed and that still the css is not found or used. So please help. Roelof

Jan. 5, 2020

Re: [Pharo-users] why is my css not found in a seaside project

by Roelof Wobben

Jan. 5, 2020

Re: [Pharo-users] can I make this so the vm would not be not responsibe when running the tests

by Roelof Wobben

Thanks. I know that im at that stage and like I said I have the feeling that Im at the stage for more then a half year. I think I know a lot of pieces but need some help to see how the pieces could help me to solve the more complex problems. But maybeÂ I want to fast and I need to concentrate on simple websites with seaside first and the problems of exercism and let the problems of Advent of Code to a later point when I have more experience.Â I know that the problems ofÂ Exercism are from easy to hard and maybe that is a better way. Roelof Op 5-1-2020 om 03:34 schreef tbrunz: > Sean, I hope your comment doesn't discourage Roelof! I might agree that > "mastery" of a given programming language could take a decade of working > with it, but it doesn't take anywhere near that long to "learn" a > programming language. > > There are other factors, such as whether or not you already know at least > one language: you'll associate what you already know with the new ways of > doing the same sorts of things. And you'll know to look for things that you > can reasonably expect a new language to provide. But the first language you > learn will probably take the longest time, as expected. > > I think learning Smalltalk/Pharo will take longer than you might expect if > the other languages you know are procedural or functional, rather than > object-oriented: You need to learn a new way of thinking when learning OOP > for the first time. And that can be hard! As humans, we're probably > "hard-wired" to think procedurally, which can be a bit of a handicap you > when starting OOP. > > You don't need to, and shouldn't expect to be able to learn everything about > a programming language immediately, as you begin learning it. Once you > learn the basics (enough to start writing programs that "do something"), you > need to begin writing programs --frequently-- and then begin the process of > incrementally adding to your understanding and knowledge of "the finer > details". You learn as you go. Reading up on the subject, including > reading others' code, helps a lot as well. Today we have GitHub to help > there! > > Don't give up, Roelof. The struggles you go through now tell you that > you've progressed to the stage of "being aware of what you don't know", > which is good: It leads you to ask the right questions that will expand your > knowledge. Finding the answers will sometimes be a challenge, but "mastery" > of a language pretty much always requires that you work through the kinds of > problems you've been having. It's what gives you "insight", summed up as > "been there, done that". Otherwise your knowledge of the language would > only be superficial (e.g., you would be able to read code examples, but you > wouldn't be able to code the examples on your own). > > We've all been through these kinds of struggles you're having now. It's > part of the process, not an indication of "you can't do it". As Sean says, > after a year of working with Pharo, you'll be offering the same kinds of > advice to others that will follow you in getting started. Just keep at it! > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Jan. 5, 2020

Re: [Pharo-users] How can we celebrate the 50th anniversary of Smalltalk?

by horrido

horrido wrote > https://medium.com/@richardeng/how-can-we-celebrate-the-50th-anniversary-of… Amazingly, no one has any suggestions! I'm afraid the 50th anniversary will pass very quietly. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 5, 2020

Re: [Pharo-users] can I make this so the vm would not be not responsibe when running the tests

by tbrunz

Sean, I hope your comment doesn't discourage Roelof! I might agree that "mastery" of a given programming language could take a decade of working with it, but it doesn't take anywhere near that long to "learn" a programming language. There are other factors, such as whether or not you already know at least one language: you'll associate what you already know with the new ways of doing the same sorts of things. And you'll know to look for things that you can reasonably expect a new language to provide. But the first language you learn will probably take the longest time, as expected. I think learning Smalltalk/Pharo will take longer than you might expect if the other languages you know are procedural or functional, rather than object-oriented: You need to learn a new way of thinking when learning OOP for the first time. And that can be hard! As humans, we're probably "hard-wired" to think procedurally, which can be a bit of a handicap you when starting OOP. You don't need to, and shouldn't expect to be able to learn everything about a programming language immediately, as you begin learning it. Once you learn the basics (enough to start writing programs that "do something"), you need to begin writing programs --frequently-- and then begin the process of incrementally adding to your understanding and knowledge of "the finer details". You learn as you go. Reading up on the subject, including reading others' code, helps a lot as well. Today we have GitHub to help there! Don't give up, Roelof. The struggles you go through now tell you that you've progressed to the stage of "being aware of what you don't know", which is good: It leads you to ask the right questions that will expand your knowledge. Finding the answers will sometimes be a challenge, but "mastery" of a language pretty much always requires that you work through the kinds of problems you've been having. It's what gives you "insight", summed up as "been there, done that". Otherwise your knowledge of the language would only be superficial (e.g., you would be able to read code examples, but you wouldn't be able to code the examples on your own). We've all been through these kinds of struggles you're having now. It's part of the process, not an indication of "you can't do it". As Sean says, after a year of working with Pharo, you'll be offering the same kinds of advice to others that will follow you in getting started. Just keep at it! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 5, 2020