February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Ubunti 14.04 32bit install error

by Markus Fritsche

Hello Brad, Yes, there's already a fixed image in the queue, however, it's stuck right now as far as I understand. Best regards, Markus On 12.02.2015 23:46, bsselfridge(a)gmail.com wrote: > One more question. Is there anyone working on fixing the image? The file > server shows that the last image build was over a month ago. > > > > ----- > Brad Selfridge > -- > View this message in context: http://forum.world.st/Ubunti-14-04-32bit-install-error-tp4805391p4805414.ht… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Feb. 13, 2015

Re: [Pharo-dev] [Pharo CI] Jenkins down 10/11 Feb

by Yuriy Tymchuk

Are there any news on this? :) > On 10 Feb 2015, at 16:50, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > This is todayâ¦ > > > >> >> There will a big update of the Inria CI infrastructure. >> >> On 10 Feb the system will go offline 5PM Paris time, it will >> be online the 12th hopefully latest. >> >> Why? For now the system just supports Win and Linux. >> This update will add the base for MacOS vitual servers. >> (If you wonder how it works now: we have a non-virtual >> Mac in our office that runs all mac buildsâ¦) >> >> Marcus > >

Feb. 13, 2015

Re: [Pharo-dev] Ubunti 14.04 32bit install error

by bsselfridge＠gmail.com

One more question. Is there anyone working on fixing the image? The file server shows that the last image build was over a month ago. ----- Brad Selfridge -- View this message in context: http://forum.world.st/Ubunti-14-04-32bit-install-error-tp4805391p4805414.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 12, 2015

Re: [Pharo-dev] changing Spec tab after opening throws MNU

by Nicolai Hess

2015-02-01 0:54 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Changing Tab name after the UI has been build fails, since it tries to set > the label to MorphicTabAdapter instead of Tab. > > I could fix it by changing in TabModel>>initialize > > label whenChangedDo: [ :new | self widget ifNotNil: [ :w | w label: new ] > ]. > to > label whenChangedDo: [ :new | self widget ifNotNil: [ :w | w widget label: > new ] ]. > > but setting it this way feels weird (not mentioning Demeter). > Maybe the MorphicTabAdapter should delegate it? > > Apart from label this also applies to icon and most likely to all other > stuff (morph, retrievingBlock, ...) > > Peter > Looking at the other spec models and morphic adapter shows: (ButtonModel for example) The model registers a whenChangedDo: block (for example for the label) the whenChangedDo: block for the attribute #label calls> self changed:#label (and changing the label on the morph actually happens in the PluggableButtonMorph #update: method) This does not work yet for a Tab morph because 1. in Tab>>#model: it does not registers itself as an dependent of the model (therefore the call self changed:#label would not reach the Tab Morph) 2. The Tab Morph does not implement #update:, so, even if we change the #model: method the Tab Morph does not know how to deal with the different update arguments I would vote for: Fix the Tab Morph, so it behaves like other morphs (register the dependents in #model: and react in #update: on all changeable attributes (label, state, icons..)) nicolai

Feb. 12, 2015

Re: [Pharo-dev] Ubunti 14.04 32bit install error

by Markus Fritsche

On 12.02.2015 22:59, bsselfridge(a)gmail.com wrote: > Any idea when the new package might be available? Not pushing, since I can > always copy the image/binary from another machine. As soon as there's a fixed image on http://files.pharo.org/platform/launcher/blessed/ ... so not in my power ;) Best regards Markus

Feb. 12, 2015

Re: [Pharo-dev] Ubunti 14.04 32bit install error

by bsselfridge＠gmail.com

Any idea when the new package might be available? Not pushing, since I can always copy the image/binary from another machine. ----- Brad Selfridge -- View this message in context: http://forum.world.st/Ubunti-14-04-32bit-install-error-tp4805391p4805411.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 12, 2015

Re: [Pharo-dev] Ubunti 14.04 32bit install error

by Markus Fritsche

On 12.02.2015 21:30, bsselfridge(a)gmail.com wrote: > I removed every package with the name "pharo" in it via the commands: > > "sudo apt-get --purge remove pharo-vm-core" > "sudo apt-get --purge remove pharo-vm-core-i386" > "sudo apt-get --purge remove pharo-sources-files" > > Then ran a "dpkg --get-selections | grep 'pharo*'" wheich returned nothing. > > Then ran the following commands: > > "sudo add-apt-repository ppa:pharo/unstable" > "sudo dpkg --add-architecture i386" > "sudo apt-get update" > "sudo apt-get install pharo-launcher" > > > Did NOT solve the problem. > Hi, the recent built pharo launcher didn't work - I had to delete the package. Unfortunately, the ppa meta data seems not to be updated accordingly. Until I have a new pharo-launcher, please download https://launchpad.net/~pharo/+archive/ubuntu/unstable/+files/pharo-launcher… and install it manually. Best regards, Markus

Feb. 12, 2015

New Cog VMs available

by Eliot Miranda

http://www.mirandabanda.org/files/Cog/VM/VM.r3254/ These fix two important bugs in the Spur VMs, so Newspeakers should update, and changes the default text encoding to UTF-8 on linux. -- best, Eliot

Feb. 12, 2015

Re: [Pharo-dev] Ubunti 14.04 32bit install error

by bsselfridge＠gmail.com

I removed every package with the name "pharo" in it via the commands: "sudo apt-get --purge remove pharo-vm-core" "sudo apt-get --purge remove pharo-vm-core-i386" "sudo apt-get --purge remove pharo-sources-files" Then ran a "dpkg --get-selections | grep 'pharo*'" wheich returned nothing. Then ran the following commands: "sudo add-apt-repository ppa:pharo/unstable" "sudo dpkg --add-architecture i386" "sudo apt-get update" "sudo apt-get install pharo-launcher" Did NOT solve the problem. ----- Brad Selfridge -- View this message in context: http://forum.world.st/Ubunti-14-04-32bit-install-error-tp4805391p4805402.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 12, 2015

Re: [Pharo-dev] [Vm-dev] re: Reducing the activity of the image

by John McIntosh

I did look at using pthread_delay_np to delay the heartbeat thread as my thought was if the image is sleeping why wake up to service the clock, etc. Difficult to measure the outcome, but one should consider that option too. On Thu, Feb 12, 2015 at 10:55 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Thu, Feb 12, 2015 at 10:45 AM, John McIntosh < > johnmci(a)smalltalkconsulting.com> wrote: > >> >> Craig so how does using pthread_cond_timedwait affect socket processing? >> The promise of nanosleep was to wake up if an interrupt arrived say on a >> socket (Mind I never actually confirmed this the case, complete hearsay...) >> > > +1. What he said. The problem with pthread_cond_timed_wait, or any other > merely delaying call is that, unless all file descriptors have been set up > to send signals on read/writability and unless the blocking call is > interruptible, the call may block for as long as it is asked, not until > that or the read/writeability of the file descriptor. > > IMO a better solution here is to a) use epoll or its equivalent kqueue; > these are like select but the state of which selectors to examine is kept > in kernel space, so the set-up overhead is vastly reduced, and b) wait for > no longer than the next scheduled delay if one is in progres. > > > Of course, the VM can do both of these things, and then there's no need > for a background process at all. Instead, when the V< scheduler finds > there's nothing to run it calls epoll or kqueue with either an infinite > timeout (if no delay is in progress) or the time until the next delay > expiration. > > Now, if only there was more time ;-) > > It strikes me that the VM can have a flag that makes it behave like this > so that e.g. some time in the Spur release cycle we can set the flag, nuke > the background process and get on with our lives. > > > >> On Thu, Feb 12, 2015 at 2:40 AM, Craig Latta <craig(a)netjam.org> wrote: >> >>> >>> >>> Hoi Norbert-- >>> >>> In 2003, while implementing remote messaging for what became the >>> Naiad distributed module system[1], I noticed excessive CPU usage during >>> idle by Squeak on MacOSX (and extremely poor remote messaging >>> performance). I prepared alternate versions of >>> ioRelinquishProcessorForMicroseconds, comparing: >>> >>> - select() (AKA aioSleepForUsecs in Ian's aio API, my starting point) >>> - pthread_cond_timedwait() >>> - nanosleep() >>> >>> pthread_cond_timedwait was the clear winner at the time. I wrote my >>> own relinquish primitive as part of the Flow external streaming >>> plugin[2], and I've been using it ever since. Still seems fine. I've >>> mentioned this before. >>> >>> >>> thanks, >>> >>> -C >>> >>> [1] http://netjam.org/naiad >>> [1] http://netjam.org/flow >>> >>> -- >>> Craig Latta >>> netjam.org >>> +31 6 2757 7177 (SMS ok) >>> + 1 415 287 3547 (no SMS) >>> >>> >> >> >> -- >> >> =========================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> >> https://www.linkedin.com/in/smalltalk >> >> =========================================================================== >> >> > > > -- > best, > Eliot > > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> https://www.linkedin.com/in/smalltalk ===========================================================================

Feb. 12, 2015