- Pharo-users - lists.pharo.org

Re: [Pharo-users] Latest Pharo and Aida/Web

by eftomi

Thanks, BenoÃ®t, it helped! However, when I visit the home page another halt happens in AIDASite>>answerTo: with exception "Error: Guest user missing?", so the digging continues â¦ Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 4, 2018

Re: [Pharo-users] VPS difficulties

by horrido

I agree totally. We shouldn't do anything to scare away people new to Pharo. It's a hard enough sell as it is. This kind of thing only undermines my advocacy. Ben Coman wrote > On Tue, 4 Dec 2018 at 02:07, Sven Van Caekenberghe < > sven@ > > wrote: > >> Yes, I can confirm that it looks like /etc/security/limits.d settings are >> not honoured inside an LXC/LXD container on Linux. I am not sure that >> there >> is a way around this, as it seems that such limits are part of the >> technology used to implement containers (and hence it might conflict with >> them by design as you could then step outside your container's limits). >> Maybe there is a way around this. >> >> Note that the VM keeps on running fine, despite the warning. It feels as >> if that warning is a bit aggressive and that there should be an option to >> silence it. >> > > Perhaps even this warning should be disabled. We've been operating a long > time with the threaded-timer as default with no adverse reports. > The warning undermines the confidence of new users and gets in the way of > their smooth first experience. > > Regarding any concern about clock jitter, perhaps the place to put this > rtprio advice is in the DelayScheduler class comment, > which I guess is where anyone having a problem with jitter would go > looking. > Here is a pertinent thread... > http://forum.world.st/Unix-heartbeat-thread-vs-itimer-td4928943i20.html > > cheers -ben > > >> On 3 Dec 2018, at 17:47, Norbert Hartl < > norbert@ > > wrote: >> > >> > I didnât read much of this thread but the VPS might give a hint. If you >> are in a virtualized server and you want to modify kernel parameters the >> underlying host needs to allow that. >> > >> > Norbert >> > >> > >> >> Am 03.12.2018 um 16:55 schrieb horrido < > horrido.hobbies@ > >: >> >> >> >> Yes, I did. I even rebooted Ubuntu. >> >> >> >> Given that this problem occurs for both Debian and Ubuntu, there must >> be >> >> some commonality that hasn't been documented. >> >> >> >> >> >> >> >> Ben Coman wrote >> >>> At https://linux.die.net/man/5/limits.conf >> >>> I read "note that all limit settings are set per login." >> >>> You haven't mentioned whether you logged out and back in again? >> >>> >> >>> cheers -ben >> >>> >> >>> On Mon, 3 Dec 2018 at 23:17, horrido < >> >> >> >>> horrido.hobbies@ >> >> >> >>> > wrote: >> >>> >> >>>> I've switched over to Ubuntu Server 18.04 LTS. I've repeated all the >> >>>> steps >> >>>> to >> >>>> arrive at Pharo installation. I'm still having the same problem: >> >>>> pthread_setschedparam failed. >> >>>> >> >>>> Here's my /etc/security/limits.d/pharo.conf: >> >>>> >> >>>> * hard rtprio 2 >> >>>> * soft rtprio 2 >> >>>> >> >>>> >> >>>> >> >>>> Sven Van Caekenberghe-2 wrote >> >>>>>> On 2 Dec 2018, at 18:40, horrido < >> >>>> >> >>>>> horrido.hobbies@ >> >>>> >> >>>>> > wrote: >> >>>>>> >> >>>>>> Bizarre. I've created a new VirtualBox image of Debian and now >> this >> >>>>>> solution >> >>>>>> no longer works! I'm still getting the thread priority warning. So >> >>>> this >> >>>>>> solution appears to be unreliable. >> >>>>> >> >>>>> Why use Debian (not that it is bad, it is just a bit more >> technical) >> ? >> >>>>> >> >>>>> I think you would have less problems using Ubuntu (it is just as >> open, >> >>>> it >> >>>>> is what everybody else is using and it is much more user friendly). >> >>>>> >> >>>>>> >> >>>>> >> >>> > <sigh> >> >>>>>> >> >>>>>> >> >>>>>> On Fri, 23 Nov 2018 at 04:02, horrido <horrido.hobbies@> >> wrote: >> >>>>>> >> >>>>>>> Okay, I've resolved everything. First, the reason why I'm getting >> the >> >>>>>>> 'pthread_setschedparam failed' error when I run Pharo under >> Debian >> is >> >>>>>>> because it must be run as 'root'! Don't ask me why, but that's >> the >> >>>>>>> reason >> >>>>>>> why Pharo can't set thread priorities. (This wasn't an issue >> under >> >>>>>>> Ubuntu >> >>>>>>> Server â go figure.) >> >>>>>>> >> >>>>>>> Second, I am now using Pharo's own SHA256 class. It's probably >> not >> as >> >>>>>>> secure >> >>>>>>> (because it doesn't use a salt value) and not as quick to execute >> >>>> (not >> >>>>>>> being >> >>>>>>> C code), but for my purpose, it doesn't really matter. >> >>>>>>> >> >>>>>>> So I can use DigitalOcean or OVH to run my web server in a VPS. >> >>>>>>> >> >>>>>> >> >>>>>> Good to hear. But you shouldn't need to run Pharo as root, >> >>>>>> just be root to create this config file.... >> >>>>>> cat < >> >>>>> >> >>> > <END | sudo tee /etc/security/limits.d/pharo.conf >> > >>>> >> >>>>> >> >>>>> * hard rtprio 2 >> >>>>>> * soft rtprio 2 >> >>>>>> END >> >>>>>> >> >>>>>> cheers -ben >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 4, 2018

Re: [Pharo-users] VPS difficulties

by Ben Coman

On Tue, 4 Dec 2018 at 02:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes, I can confirm that it looks like /etc/security/limits.d settings are > not honoured inside an LXC/LXD container on Linux. I am not sure that there > is a way around this, as it seems that such limits are part of the > technology used to implement containers (and hence it might conflict with > them by design as you could then step outside your container's limits). > Maybe there is a way around this. > > Note that the VM keeps on running fine, despite the warning. It feels as > if that warning is a bit aggressive and that there should be an option to > silence it. > Perhaps even this warning should be disabled. We've been operating a long time with the threaded-timer as default with no adverse reports. The warning undermines the confidence of new users and gets in the way of their smooth first experience. Regarding any concern about clock jitter, perhaps the place to put this rtprio advice is in the DelayScheduler class comment, which I guess is where anyone having a problem with jitter would go looking. Here is a pertinent thread... http://forum.world.st/Unix-heartbeat-thread-vs-itimer-td4928943i20.html cheers -ben > On 3 Dec 2018, at 17:47, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > I didnât read much of this thread but the VPS might give a hint. If you > are in a virtualized server and you want to modify kernel parameters the > underlying host needs to allow that. > > > > Norbert > > > > > >> Am 03.12.2018 um 16:55 schrieb horrido <horrido.hobbies(a)gmail.com>: > >> > >> Yes, I did. I even rebooted Ubuntu. > >> > >> Given that this problem occurs for both Debian and Ubuntu, there must be > >> some commonality that hasn't been documented. > >> > >> > >> > >> Ben Coman wrote > >>> At https://linux.die.net/man/5/limits.conf > >>> I read "note that all limit settings are set per login." > >>> You haven't mentioned whether you logged out and back in again? > >>> > >>> cheers -ben > >>> > >>> On Mon, 3 Dec 2018 at 23:17, horrido < > >> > >>> horrido.hobbies@ > >> > >>> > wrote: > >>> > >>>> I've switched over to Ubuntu Server 18.04 LTS. I've repeated all the > >>>> steps > >>>> to > >>>> arrive at Pharo installation. I'm still having the same problem: > >>>> pthread_setschedparam failed. > >>>> > >>>> Here's my /etc/security/limits.d/pharo.conf: > >>>> > >>>> * hard rtprio 2 > >>>> * soft rtprio 2 > >>>> > >>>> > >>>> > >>>> Sven Van Caekenberghe-2 wrote > >>>>>> On 2 Dec 2018, at 18:40, horrido < > >>>> > >>>>> horrido.hobbies@ > >>>> > >>>>> > wrote: > >>>>>> > >>>>>> Bizarre. I've created a new VirtualBox image of Debian and now this > >>>>>> solution > >>>>>> no longer works! I'm still getting the thread priority warning. So > >>>> this > >>>>>> solution appears to be unreliable. > >>>>> > >>>>> Why use Debian (not that it is bad, it is just a bit more technical) > ? > >>>>> > >>>>> I think you would have less problems using Ubuntu (it is just as > open, > >>>> it > >>>>> is what everybody else is using and it is much more user friendly). > >>>>> > >>>>>> > >>>>> > >>> <sigh> > >>>>>> > >>>>>> > >>>>>> On Fri, 23 Nov 2018 at 04:02, horrido <horrido.hobbies@> > wrote: > >>>>>> > >>>>>>> Okay, I've resolved everything. First, the reason why I'm getting > the > >>>>>>> 'pthread_setschedparam failed' error when I run Pharo under Debian > is > >>>>>>> because it must be run as 'root'! Don't ask me why, but that's the > >>>>>>> reason > >>>>>>> why Pharo can't set thread priorities. (This wasn't an issue under > >>>>>>> Ubuntu > >>>>>>> Server â go figure.) > >>>>>>> > >>>>>>> Second, I am now using Pharo's own SHA256 class. It's probably not > as > >>>>>>> secure > >>>>>>> (because it doesn't use a salt value) and not as quick to execute > >>>> (not > >>>>>>> being > >>>>>>> C code), but for my purpose, it doesn't really matter. > >>>>>>> > >>>>>>> So I can use DigitalOcean or OVH to run my web server in a VPS. > >>>>>>> > >>>>>> > >>>>>> Good to hear. But you shouldn't need to run Pharo as root, > >>>>>> just be root to create this config file.... > >>>>>> cat < > >>>>> > >>> <END | sudo tee /etc/security/limits.d/pharo.conf > >>>> > >>>>> > >>>>> * hard rtprio 2 > >>>>>> * soft rtprio 2 > >>>>>> END > >>>>>> > >>>>>> cheers -ben > >

Dec. 3, 2018

Re: [Pharo-users] Latest Pharo and Aida/Web

by Benoit St-Jean

If I'm not mistaken (according to the fact that both class comments are exactly the same), SecureHashAlgorithm (in Squeak) is the exact same thing as class SHA1 (in Pharo)... Just updating the code with the "new" class name will probably do the job! ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein) On Monday, December 3, 2018, 4:18:55 p.m. EST, eftomi <tomaz.turk(a)ef.uni-lj.si> wrote: Hi, I'm trying to run Aida/Web on Pharo 5.0, 6.1 and 7.0 with no luck. After package inclusion with Catalog Browser, the initialisation with SwazooAida demoStart wasn't working, since Timestamp was not present. After I "faked" it with DateAndTime, the web server is running, but if I visit the initial web address http://localhost:8888/, I get his error: WebSecurityManager class>>hashPassword: (SecureHashAlgorithm is Undeclared). Before I continue with exploration & debugging, I'd like to know how far from a working and stable team is Aida & latest Pharo (if somebody knows, of course). I'm a beginner with Smalltalk and Aida seems to be very nice framework, however there are other options as well, without any challenges for a newbie :-) Thanks, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 3, 2018

Latest Pharo and Aida/Web

by eftomi

Hi, I'm trying to run Aida/Web on Pharo 5.0, 6.1 and 7.0 with no luck. After package inclusion with Catalog Browser, the initialisation with SwazooAida demoStart wasn't working, since Timestamp was not present. After I "faked" it with DateAndTime, the web server is running, but if I visit the initial web address http://localhost:8888/, I get his error: WebSecurityManager class>>hashPassword: (SecureHashAlgorithm is Undeclared). Before I continue with exploration & debugging, I'd like to know how far from a working and stable team is Aida & latest Pharo (if somebody knows, of course). I'm a beginner with Smalltalk and Aida seems to be very nice framework, however there are other options as well, without any challenges for a newbie :-) Thanks, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 3, 2018

Re: [Pharo-users] can I improve this

by Benoit St-Jean

Wouldn't be that hard to implement.Â We just need a modulo (like I did) when sending #next to wrap around... Or even better: a "cyclic" iterator, something like #withWrapDo: ? ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein) On Monday, December 3, 2018, 1:28:09 p.m. EST, phil--- via Pharo-users <pharo-users(a)lists.pharo.org> wrote: CyclicReadStream. Not in base Pharo. I wish. We have atWrap: but not the best. Phil On Mon, Dec 3, 2018 at 1:17 PM Richard O'Keefe <raoknz(a)gmail.com> wrote: "if I use do:Â Â this ends at the end of the array."True.Â But all that means is that you have to keen on using #do:. Processing an array repeatedly is as simple asÂ [true] whileTrue: [Â Â anArray do: [:each |Â Â Â ...]] I had intended to twist this into Â [changes anySatisfy: [:change | ...]] whileFalse. However, in this case your second alternative has much to recommend it.The control flow is simple.Â There's no magic about it.Â It's anunusual setup, so no need to get fancy. Â seen := Set new.Â frequency := 0.Â found := false.Â i := changes size.Â [found] whileFalse: [Â Â i := i = changes size ifTrue: [1] ifFalse: [i+1].Â Â frequency := frequencyÂ + (changes at: i).Â Â found := seen includes: frequency.Â Â seen add: frequency]. I like this better than what I had. If we _were_ to get fancy, then introducing a CyclicReadStreamclass and doingÂ Â seen := Set new.Â Â frequency := 0.Â Â found := false.Â Â stream := CyclicReadStream on: self changes.Â Â [found] whileFalse: [Â Â Â frequency := frequencyÂ + stream next.Â Â Â found := seen includes: frequency.Â Â Â seen add: frequency].wouldn't shrink the code much.Â Oddly enough, I've encounteredproblems in previous Advent of Code exercises where CyclicReadStreamwould have been handy.Â But just for this case?Â No. On Tue, 4 Dec 2018 at 00:25, Roelof Wobben <r.wobben(a)home.nl> wrote: hello Richard, Thanks, I figured that out already. What I do not get is how to read the array multiple times. if I use do:Â Â this ends at the end of the array. Or I must use something as this : index := 0 if index > array length Â Â Â index =:Â 1 else index := index + 1 and then read the number with array at: index Roelof Op 3-12-2018 om 10:08 schreef Richard O'Keefe: Roelof Wobben wrote "I have to reread the file till the adding causes the same outcomeÂ as we had already" You have to process the *sequence of changes* repeatedly; you DON't have to *reread the file*.Â Somebody already made this point. Having read the changes into an array, you can iterate repeatedly over that array. to find the first repeated frequency given a sequence of changes Â Â make an empty Set to hold the sums that have been seen so far. Â Â set the frequency to 0. Â Â loop forever Â Â Â Â for each change in the changes Â Â Â Â Â Â increment the frequency by the change. Â Â Â Â Â Â if the frequency is in the set Â Â Â Â Â Â Â Â return the frequency Â Â Â Â Â Â otherwise add the frequency to the set. Â partTwo: aFileName Â Â Transcript print: (self firstRepeatedFrequency: (self changesFrom: aFileName)); cr; flush. On Mon, 3 Dec 2018 at 19:31, Roelof Wobben <r.wobben(a)home.nl> wrote: Thanks, For the second I have to take a good look. I have to reread the file till the adding causes the same outcomeÂ as we had already so for example if we have the sequence : +3, +3, +4, -2, -4 it has as outcome : 3 6 10 8 4 so no outcome is there a second time so we repeat the sequence 7 10 the 10 shows up a second time so there we have our answer. Roelof Op 3-12-2018 om 03:45 schreef Richard O'Keefe: The key question is "what do you mean by improve"? I'd start by asking "what are you doing that you will still have to do in part 2, and what won't you do?"Â So looking at part 2, you will want to convert the lines to integers, and Â input := Array streamContents: [:lines | Â Â 'input.txt' asFileReference readStreamDo: [:in | Â Â Â [in atEnd] whileFalse: [lines nextPut: in nextLine asInteger]]]. gives you a chunk of code you can use in both parts.Â So you might want to have Day1 Â changesFrom: aFileName Â Â ^Array streamContents: [:changes | Â Â Â aFileName asFileReference readStreamDo: [:in | Â Â Â Â [in atEnd] whileFalse: [changes nextPut: in nextLine asInteger]]] Â partOne: aFileName Â Â ^(self changesFrom: aFileName) sum Â partTwo: aFileName Â Â ... The file name should not be wired in because you want some test files.

Dec. 3, 2018

Re: [Pharo-users] can I improve this

by phil＠highoctane.be

CyclicReadStream. Not in base Pharo. I wish. We have atWrap: but not the best. Phil On Mon, Dec 3, 2018 at 1:17 PM Richard O'Keefe <raoknz(a)gmail.com> wrote: > "if I use do: this ends at the end of the array." > True. But all that means is that you have to keen on using #do:. > > Processing an array repeatedly is as simple as > [true] whileTrue: [ > anArray do: [:each | > ...]] > > I had intended to twist this into > > [changes anySatisfy: [:change | ...]] whileFalse. > > However, in this case your second alternative has much to recommend it. > The control flow is simple. There's no magic about it. It's an > unusual setup, so no need to get fancy. > > seen := Set new. > frequency := 0. > found := false. > i := changes size. > [found] whileFalse: [ > i := i = changes size ifTrue: [1] ifFalse: [i+1]. > frequency := frequency + (changes at: i). > found := seen includes: frequency. > seen add: frequency]. > > I like this better than what I had. > > If we _were_ to get fancy, then introducing a CyclicReadStream > class and doing > seen := Set new. > frequency := 0. > found := false. > stream := CyclicReadStream on: self changes. > [found] whileFalse: [ > frequency := frequency + stream next. > found := seen includes: frequency. > seen add: frequency]. > wouldn't shrink the code much. Oddly enough, I've encountered > problems in previous Advent of Code exercises where CyclicReadStream > would have been handy. But just for this case? No. > > > On Tue, 4 Dec 2018 at 00:25, Roelof Wobben <r.wobben(a)home.nl> wrote: > >> hello Richard, >> >> Thanks, I figured that out already. >> What I do not get is how to read the array multiple times. >> >> if I use do: this ends at the end of the array. >> >> Or I must use something as this : >> >> index := 0 >> if index > array length >> index =: 1 >> else >> index := index + 1 >> >> >> and then read the number with array at: index >> >> Roelof >> >> >> Op 3-12-2018 om 10:08 schreef Richard O'Keefe: >> >> Roelof Wobben wrote >> "I have to reread the file till the adding causes the same outcome as >> we had already" >> You have to process the *sequence of changes* repeatedly; >> you DON't have to *reread the file*. Somebody already made this point. >> Having read the changes into an array, you can iterate repeatedly over >> that array. >> >> to find the first repeated frequency given a sequence of changes >> make an empty Set to hold the sums that have been seen so far. >> set the frequency to 0. >> loop forever >> for each change in the changes >> increment the frequency by the change. >> if the frequency is in the set >> return the frequency >> otherwise add the frequency to the set. >> >> partTwo: aFileName >> Transcript print: (self firstRepeatedFrequency: (self changesFrom: >> aFileName)); cr; flush. >> >> On Mon, 3 Dec 2018 at 19:31, Roelof Wobben <r.wobben(a)home.nl> wrote: >> >>> Thanks, >>> >>> For the second I have to take a good look. >>> >>> I have to reread the file till the adding causes the same outcome as we >>> had already >>> >>> so for example if we have the sequence : >>> >>> +3, +3, +4, -2, -4 >>> >>> it has as outcome : >>> >>> 3 6 10 8 4 >>> >>> so no outcome is there a second time so we repeat the sequence >>> >>> >>> 7 10 >>> >>> the 10 shows up a second time so there we have our answer. >>> >>> >>> Roelof >>> >>> >>> >>> Op 3-12-2018 om 03:45 schreef Richard O'Keefe: >>> >>> The key question is "what do you mean by improve"? >>> I'd start by asking "what are you doing that you will still have to do in >>> part 2, and what won't you do?" So looking at part 2, you will want to >>> convert the lines to integers, and >>> input := Array streamContents: [:lines | >>> 'input.txt' asFileReference readStreamDo: [:in | >>> [in atEnd] whileFalse: [lines nextPut: in nextLine asInteger]]]. >>> gives you a chunk of code you can use in both parts. So you might >>> want to have >>> >>> Day1 >>> changesFrom: aFileName >>> ^Array streamContents: [:changes | >>> aFileName asFileReference readStreamDo: [:in | >>> [in atEnd] whileFalse: [changes nextPut: in nextLine asInteger]]] >>> partOne: aFileName >>> ^(self changesFrom: aFileName) sum >>> partTwo: aFileName >>> ... >>> The file name should not be wired in because you want some test files. >>> >>> >>> >>> >>

Dec. 3, 2018

Re: [Pharo-users] VPS difficulties

by Sven Van Caekenberghe

Yes, I can confirm that it looks like /etc/security/limits.d settings are not honoured inside an LXC/LXD container on Linux. I am not sure that there is a way around this, as it seems that such limits are part of the technology used to implement containers (and hence it might conflict with them by design as you could then step outside your container's limits). Maybe there is a way around this. Note that the VM keeps on running fine, despite the warning. It feels as if that warning is a bit aggressive and that there should be an option to silence it. > On 3 Dec 2018, at 17:47, Norbert Hartl <norbert(a)hartl.name> wrote: > > I didnât read much of this thread but the VPS might give a hint. If you are in a virtualized server and you want to modify kernel parameters the underlying host needs to allow that. > > Norbert > > >> Am 03.12.2018 um 16:55 schrieb horrido <horrido.hobbies(a)gmail.com>: >> >> Yes, I did. I even rebooted Ubuntu. >> >> Given that this problem occurs for both Debian and Ubuntu, there must be >> some commonality that hasn't been documented. >> >> >> >> Ben Coman wrote >>> At https://linux.die.net/man/5/limits.conf >>> I read "note that all limit settings are set per login." >>> You haven't mentioned whether you logged out and back in again? >>> >>> cheers -ben >>> >>> On Mon, 3 Dec 2018 at 23:17, horrido < >> >>> horrido.hobbies@ >> >>> > wrote: >>> >>>> I've switched over to Ubuntu Server 18.04 LTS. I've repeated all the >>>> steps >>>> to >>>> arrive at Pharo installation. I'm still having the same problem: >>>> pthread_setschedparam failed. >>>> >>>> Here's my /etc/security/limits.d/pharo.conf: >>>> >>>> * hard rtprio 2 >>>> * soft rtprio 2 >>>> >>>> >>>> >>>> Sven Van Caekenberghe-2 wrote >>>>>> On 2 Dec 2018, at 18:40, horrido < >>>> >>>>> horrido.hobbies@ >>>> >>>>> > wrote: >>>>>> >>>>>> Bizarre. I've created a new VirtualBox image of Debian and now this >>>>>> solution >>>>>> no longer works! I'm still getting the thread priority warning. So >>>> this >>>>>> solution appears to be unreliable. >>>>> >>>>> Why use Debian (not that it is bad, it is just a bit more technical) ? >>>>> >>>>> I think you would have less problems using Ubuntu (it is just as open, >>>> it >>>>> is what everybody else is using and it is much more user friendly). >>>>> >>>>>> >>>>> >>> <sigh> >>>>>> >>>>>> >>>>>> On Fri, 23 Nov 2018 at 04:02, horrido <horrido.hobbies@> wrote: >>>>>> >>>>>>> Okay, I've resolved everything. First, the reason why I'm getting the >>>>>>> 'pthread_setschedparam failed' error when I run Pharo under Debian is >>>>>>> because it must be run as 'root'! Don't ask me why, but that's the >>>>>>> reason >>>>>>> why Pharo can't set thread priorities. (This wasn't an issue under >>>>>>> Ubuntu >>>>>>> Server â go figure.) >>>>>>> >>>>>>> Second, I am now using Pharo's own SHA256 class. It's probably not as >>>>>>> secure >>>>>>> (because it doesn't use a salt value) and not as quick to execute >>>> (not >>>>>>> being >>>>>>> C code), but for my purpose, it doesn't really matter. >>>>>>> >>>>>>> So I can use DigitalOcean or OVH to run my web server in a VPS. >>>>>>> >>>>>> >>>>>> Good to hear. But you shouldn't need to run Pharo as root, >>>>>> just be root to create this config file.... >>>>>> cat < >>>>> >>> <END | sudo tee /etc/security/limits.d/pharo.conf >>>> >>>>> >>>>> * hard rtprio 2 >>>>>> * soft rtprio 2 >>>>>> END >>>>>> >>>>>> cheers -ben >>>> >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Dec. 3, 2018

Re: [Pharo-users] can I improve this

by Benoit St-Jean

It's just a matter of taste and/or habit.Â Quite frankly, I never think about using #streamContents nor #readStream or other variations since I've always had to write that kinda code "the long way" since 1992 ! ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein) On Monday, December 3, 2018, 11:09:31 a.m. EST, Roelof Wobben <r.wobben(a)home.nl> wrote: Op 3-12-2018 om 17:01 schreef Benoit St-Jean via Pharo-users: Many many many thanks For me too and that is the answer I expect Two question, Why is trough StandardFileStream a line and can this also be rewritten with a StreamContents Roelof

Dec. 3, 2018

Re: [Pharo-users] VPS difficulties

by Norbert Hartl

I didnât read much of this thread but the VPS might give a hint. If you are in a virtualized server and you want to modify kernel parameters the underlying host needs to allow that. Norbert > Am 03.12.2018 um 16:55 schrieb horrido <horrido.hobbies(a)gmail.com>: > > Yes, I did. I even rebooted Ubuntu. > > Given that this problem occurs for both Debian and Ubuntu, there must be > some commonality that hasn't been documented. > > > > Ben Coman wrote >> At https://linux.die.net/man/5/limits.conf <https://linux.die.net/man/5/limits.conf> >> I read "note that all limit settings are set per login." >> You haven't mentioned whether you logged out and back in again? >> >> cheers -ben >> >> On Mon, 3 Dec 2018 at 23:17, horrido < > >> horrido.hobbies@ > >> > wrote: >> >>> I've switched over to Ubuntu Server 18.04 LTS. I've repeated all the >>> steps >>> to >>> arrive at Pharo installation. I'm still having the same problem: >>> pthread_setschedparam failed. >>> >>> Here's my /etc/security/limits.d/pharo.conf: >>> >>> * hard rtprio 2 >>> * soft rtprio 2 >>> >>> >>> >>> Sven Van Caekenberghe-2 wrote >>>>> On 2 Dec 2018, at 18:40, horrido < >>> >>>> horrido.hobbies@ >>> >>>> > wrote: >>>>> >>>>> Bizarre. I've created a new VirtualBox image of Debian and now this >>>>> solution >>>>> no longer works! I'm still getting the thread priority warning. So >>> this >>>>> solution appears to be unreliable. >>>> >>>> Why use Debian (not that it is bad, it is just a bit more technical) ? >>>> >>>> I think you would have less problems using Ubuntu (it is just as open, >>> it >>>> is what everybody else is using and it is much more user friendly). >>>> >>>>> >>>> >> <sigh> >>>>> >>>>> >>>>> On Fri, 23 Nov 2018 at 04:02, horrido <horrido.hobbies@> wrote: >>>>> >>>>>> Okay, I've resolved everything. First, the reason why I'm getting the >>>>>> 'pthread_setschedparam failed' error when I run Pharo under Debian is >>>>>> because it must be run as 'root'! Don't ask me why, but that's the >>>>>> reason >>>>>> why Pharo can't set thread priorities. (This wasn't an issue under >>>>>> Ubuntu >>>>>> Server â go figure.) >>>>>> >>>>>> Second, I am now using Pharo's own SHA256 class. It's probably not as >>>>>> secure >>>>>> (because it doesn't use a salt value) and not as quick to execute >>> (not >>>>>> being >>>>>> C code), but for my purpose, it doesn't really matter. >>>>>> >>>>>> So I can use DigitalOcean or OVH to run my web server in a VPS. >>>>>> >>>>> >>>>> Good to hear. But you shouldn't need to run Pharo as root, >>>>> just be root to create this config file.... >>>>> cat < >>>> >> <END | sudo tee /etc/security/limits.d/pharo.conf >>> >>>> >>>> * hard rtprio 2 >>>>> * soft rtprio 2 >>>>> END >>>>> >>>>> cheers -ben >>> > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html>

Dec. 3, 2018