- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] iPad version does not work ?[SEC=UNCLASSIFIED]

by Esteban Lorenzano

I added some hints here: https://github.com/pharo-project/pharo-vm Esteban On 25 Feb 2014, at 10:41, phil(a)highoctane.be wrote: > You will need an Apple Developer id and for the rest, follow the build procedure and run on the iPad which is connected to your Mac. > You'll need to generate and Xcode project from Cmake to get this to work. > Also, be ready to delete the app often on the device before running it again as there are issues if you do not (like application not being updated). > > Phil

Feb. 25, 2014

Re: [Pharo-dev] [Zinc] Progress bar during download?

by Sven Van Caekenberghe

On 25 Feb 2014, at 10:19, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-02-25 9:37 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Pavel, > > I am surprised that a die hard hacker like you could not find it yourself ;-) > > Anyway, this is how you do it: > > UIManager default informUserDuring: [ :bar | > [ > ZnClient new > url: 'http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/27.0/runtimes/xul…'; > signalProgress: true; > downloadTo: 'xulrunner.zip' ] > on: HTTPProgress > do: [ :progress | > bar label: progress printString. > progress isEmpty ifFalse: [ bar current: progress percentage ]. > progress resume ] ]. > > First you enable progress signalling, then you catch HTTPProgress and do something with it. > > Sven > > On 25 Feb 2014, at 09:04, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > Hi, > > > > is there a way how to show progress bar during download of a big files using #downloadTo: message of the ZnClient? The image is not responsive for a long time and users may think it's frozen. > > > > example: > > > > ZnClient new url: 'http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/27.0/runtimes/xul…'; > > downloadTo: 'xulrunner.zip'. > > > > Cheers, > > -- Pavel > > > > > Or: > > [ :bar | > [ > ZnClient new > url: 'http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/27.0/runtimes/xul…'; > signalProgress: true; > downloadTo: 'xulrunner.zip' ] > on: HTTPProgress > do: [ :progress | > bar label: progress printString. > progress isEmpty ifFalse: [ bar current: progress percentage ]. > progress resume ] ] > asJob run. Ah, yes, that is beautiful, thanks. Sven

Feb. 25, 2014

Re: [Pharo-dev] [Zinc] Progress bar during download?

by phil＠highoctane.be

Hey, nice this aJob thing.

Feb. 25, 2014

[Pharo Consortium] New Sponsor: Object Profile

by Marcus Denker

The Pharo Consortium is very happy to announce that Object Profile is supporting the Pharo Consortium as a Sponsor. More about - Object Profile: http://objectprofile.com - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org ==== ( This actually happened some weeks ago alreadyâ¦ sorry for the late announce. There is already another member listed (to be announced) and yet another will be added soon. In addition, we are nearly finished with setting up the infrastructure for the consortium membersâ¦ so if you are one of those and wonder: Soon (as in: this week). Sorry for the delay! )

Feb. 25, 2014

Re: [Pharo-dev] iPad version does not work ?[SEC=UNCLASSIFIED]

by phil＠highoctane.be

You will need an Apple Developer id and for the rest, follow the build procedure and run on the iPad which is connected to your Mac. You'll need to generate and Xcode project from Cmake to get this to work. Also, be ready to delete the app often on the device before running it again as there are issues if you do not (like application not being updated). Phil

Feb. 25, 2014

Re: [Pharo-dev] New methods for the String class

by phil＠highoctane.be

Getting to appreciate all of those facets of Smalltalk takes time and dedication. So much to learn. Anyway, the journey is rewarding. I do not think that the current education system is producing people who want to explore etc. My wife is a maths teacher (for teens for the two years before university, 6+2 hours of math a week) and well, their attitude isn't too encouraging (there are 2 out of 30 who would be picking this up). This isn't deterring me from exposing them to Pharo tough. Phil On Tue, Feb 25, 2014 at 12:10 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Mon, Feb 24, 2014 at 2:47 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 24.02.2014 um 23:09 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> On Mon, Feb 24, 2014 at 1:58 PM, Norbert Hartl <norbert(a)hartl.name>wrote: >> >>> >>> Am 24.02.2014 um 22:19 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>> >>> On Mon, Feb 24, 2014 at 12:29 PM, Alexandre Bergel< >>> alexandre.bergel(a)me.com> wrote: >>> >>>> Would be great to have: 'ConfigurationOfRoassal' chopCamel => >>>> #('Configuration' 'Of' 'Roassal'). >>>> >>> >>> 'ConfigurationOfRoassal' piecesCutWhere: [:a :b| a isLowercase and: [b >>> isUppercase]] an OrderedCollection('Configuration' 'Of' 'Roassal') >>> >>> It's too trivial, surely. >>> >>> >>> No it is not. Because you have to know about it. Thanks for that one. >>> >>> "I learned something today[tm]" >>> >> >> But the real things to learn are the Method Finder and the browser. >> Adding a lot of names that are known to those that know some scripting >> language du jour, but are incomprehensible to me, and no doubt many others, >> is not doing anything for anybody, except trying to be pointlessly cool. >> Trying to encourage programmers to use the ability of the system to >> self-introspect and self-document is giving them general skills they can >> build upon. So a project to improve the UI so that programmers are led to >> tools they can use for discovery seems worth-while to me, while adding yet >> more short-hand to hand-hold the ignorant isn't helping, IMHO. >> >> I agree that adding a lot of names is not helping because that might be >> the reason I didn't know that selector. What kind of selectors are the >> right ones I'm not the one to judge. But to be honest if I think about a >> collection the selector #piecesCutWhere: is not intuitive to me, too. So >> I'm glad you brought that to my attention. >> > > I get that. All naming is difficult. That there are many different ways > to say the same thing in natural language is I think a common problem to > many languages, especially English. Just remember the last time you tried > to do some free text search for some phrase. Takes me ages to find old > messages in email. So even if method is well-named, it likely has only one > of a number of plausible good names. And if it has a usefully short > nickname (look at unix and lisp, cat & cdr etc) then it must likely be > learned by rote. > > So the issue is not naming; it is how to /find/ functionality. And so in > Smalltalk the issue is how to encourage programmers to go find things. The > MessageFinder is amazing. But people don't use it. If they did no one > would be proposing to add chomp to the standard library. > > <old man alert>When I learnt Smalltalk there were several factors that > made it easy for me to learn. It was much smaller. I thought it was cool. > I had the time to learn it. But when I learnt it the browser was simple, > refactoring hadn't been invented, there was no MethodFinder, and there was > almost _no_ documentation. Basically I learnt it by playing with it, > exploring it, reading it, building it.</old man alert> > > So why aren't people taking the time to learn it today? Is it the > system's fault? Is it too big? Are the readable parts of the system > non-existent, or too difficult to find? Is it some cultural change that > means people can't learn such systems any more? Was it only learnable by a > few people back in the day and it remains unsuitable for a mass audience? > Is it impossible to design user interfaces that invite exploration? Do > people no longer want to play with the system but instead want to use it to > get something done fast, and can't spare the time to learn it properly? > Are computing languages like English, and every programming language must > adopt the conventions and vocabulary of the most popular? Is inheritance > too hard to navigate to discover that SequenceableCollection has lots of > useful String mehtods, and some useful methods on ByteString are in String, > etc? > > I think suggestions that one add functionality that already exists in the > system point to some interesting issues. And I think someone with an HCI > or UI bent might get somewhere approaching these questions systematically. > > > >> thanks again, >> > > you're welcome :-) > > >> >> Norbert >> >> >>> Norbert >>> >>> >>>> Alexandre >>>> >>>> >>>> On Feb 24, 2014, at 2:30 PM, Daniela Meneses <daniela11290(a)gmail.com> >>>> wrote: >>>> >>>> > Hi to all, >>>> > >>>> > As you may know I'm working on in some improvements for the String >>>> class. Until now I implemented some missing tests. Right now I'm looking >>>> forward to add new methods that could be useful based on Ruby API ( >>>> http://www.ruby-doc.org/core-2.1.0/String.html) These are a few of >>>> the methods that I'm planning to implement: >>>> > >>>> > * chomp(separator=$/) -> new_str >>>> > * chop() -> new_str >>>> > * ljust(integer, padstr='') ->new_str >>>> > * next -> new_str >>>> > * partition(sep) -> [head, sep, tail] >>>> > >>>> > Could you help to find out if these methods are already available for >>>> the String class? >>>> > >>>> > If you have any idea of new methods for the string class, will be >>>> really welcome. >>>> > >>>> > -- >>>> > Cheers, >>>> > Daniela Meneses >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >>> >> >> >> -- >> best, >> Eliot >> >> >> > > > -- > best, > Eliot >

Feb. 25, 2014

Re: [Pharo-dev] New methods for the String class

by phil＠highoctane.be

On that front, MethodFinder and Spotlight should be a bit more aligned. Try searching for * or \\ in spotlight and you'll get nothing. Very annoying. Autocomplete maybe waiting for a couple chars in order to work. The searchbox in the VW browser is indeed useful. There is the Nautilus Finder plugin one can add (not there by default) but who is going to find out as Nautilus plugins are in a kind of bad state (some really do weird things and most have no description). Phil On Mon, Feb 24, 2014 at 11:09 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Mon, Feb 24, 2014 at 1:58 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 24.02.2014 um 22:19 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> >> >> On Mon, Feb 24, 2014 at 12:29 PM, Alexandre Bergel< >> alexandre.bergel(a)me.com> wrote: >> >>> Would be great to have: 'ConfigurationOfRoassal' chopCamel => >>> #('Configuration' 'Of' 'Roassal'). >>> >> >> 'ConfigurationOfRoassal' piecesCutWhere: [:a :b| a isLowercase and: [b >> isUppercase]] an OrderedCollection('Configuration' 'Of' 'Roassal') >> >> It's too trivial, surely. >> >> >> No it is not. Because you have to know about it. Thanks for that one. >> >> "I learned something today[tm]" >> > > But the real things to learn are the Method Finder and the browser. > Adding a lot of names that are known to those that know some scripting > language du jour, but are incomprehensible to me, and no doubt many others, > is not doing anything for anybody, except trying to be pointlessly cool. > Trying to encourage programmers to use the ability of the system to > self-introspect and self-document is giving them general skills they can > build upon. So a project to improve the UI so that programmers are led to > tools they can use for discovery seems worth-while to me, while adding yet > more short-hand to hand-hold the ignorant isn't helping, IMHO. > > >> Norbert >> >> >>> Alexandre >>> >>> >>> On Feb 24, 2014, at 2:30 PM, Daniela Meneses <daniela11290(a)gmail.com> >>> wrote: >>> >>> > Hi to all, >>> > >>> > As you may know I'm working on in some improvements for the String >>> class. Until now I implemented some missing tests. Right now I'm looking >>> forward to add new methods that could be useful based on Ruby API ( >>> http://www.ruby-doc.org/core-2.1.0/String.html) These are a few of the >>> methods that I'm planning to implement: >>> > >>> > * chomp(separator=$/) -> new_str >>> > * chop() -> new_str >>> > * ljust(integer, padstr='') ->new_str >>> > * next -> new_str >>> > * partition(sep) -> [head, sep, tail] >>> > >>> > Could you help to find out if these methods are already available for >>> the String class? >>> > >>> > If you have any idea of new methods for the string class, will be >>> really welcome. >>> > >>> > -- >>> > Cheers, >>> > Daniela Meneses >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >> >> >> -- >> best, >> Eliot >> >> >> > > > -- > best, > Eliot >

Feb. 25, 2014

Re: [Pharo-dev] [Zinc] Progress bar during download?

by Nicolai Hess

2014-02-25 9:37 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Pavel, > > I am surprised that a die hard hacker like you could not find it yourself > ;-) > > Anyway, this is how you do it: > > UIManager default informUserDuring: [ :bar | > [ > ZnClient new > url: ' > http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/27.0/runtimes/xul… > '; > signalProgress: true; > downloadTo: 'xulrunner.zip' ] > on: HTTPProgress > do: [ :progress | > bar label: progress printString. > progress isEmpty ifFalse: [ bar current: progress > percentage ]. > progress resume ] ]. > > First you enable progress signalling, then you catch HTTPProgress and do > something with it. > > Sven > > On 25 Feb 2014, at 09:04, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > Hi, > > > > is there a way how to show progress bar during download of a big files > using #downloadTo: message of the ZnClient? The image is not responsive for > a long time and users may think it's frozen. > > > > example: > > > > ZnClient new url: ' > http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/27.0/runtimes/xul… > '; > > downloadTo: 'xulrunner.zip'. > > > > Cheers, > > -- Pavel > > > Or: [ :bar | [ ZnClient new url: ' http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/27.0/runtimes/xul… '; signalProgress: true; downloadTo: 'xulrunner.zip' ] on: HTTPProgress do: [ :progress | bar label: progress printString. progress isEmpty ifFalse: [ bar current: progress percentage ]. progress resume ] ] asJob run.

Feb. 25, 2014

hashMultiply

by phil＠highoctane.be

I am currently reading through the Hashing in Smalltalk book ( http://www.lulu.com/shop/andres-valloud/hashing-in-smalltalk-theory-and-pra…) and, my head hurting notwithstanding, there are indeed a ton of gems in this system. As he mentions, doing the exercises brings a lot of extra :-) When going to 64-bit, and with the new ObjectMemory scheme, I guess a couple of identity hashing functions will come under scrutiny. e.g. SmallInteger>>hashMultiply | low | low := self bitAnd: 16383. ^(16r260D * low + ((16r260D * (self bitShift: -14) + (16r0065 * low) bitAnd: 16383) * 16384)) bitAnd: 16r0FFFFFFF which will need some more bits. I had a look at how it was done in VisualWorks; hashMultiply "Multiply the receiver by 16r0019660D mod 2^28 without using large integer arithmetic for speed. The constant is a generator of the multiplicative subgroup of Z_2^30, see Knuth's TAOCP vol 2." <primitive: 1747> | low14Bits | low14Bits := self bitAnd: 16r3FFF. ^16384 * (16r260D * (self bitShift: -14) + (16r0065 * low14Bits) bitAnd: 16r3FFF) + (16r260D * low14Bits) bitAnd: 16rFFFFFFF The hashing book version has: multiplication "Computes self times 1664525 mod 2^38 while avoiding overflow into a large integer by making the multiplication into two 14 bits chunks. Do not use any division or modulo operation." | lowBits highBits| lowBits := self bitAnd: 16r3FFF. highBits := self bitShift: -14. ^(lowBits * 16r260D) + (((lowBits * 16r0065) bitAnd: 16r3FFF) bitShift: 14) + (((highBits * 16r260D) bitAnd: 16r3FFF) bitShift: 14) bitAnd: 16rFFFFFFF So, 16384 * is the same as bitShift: 14 and it looks like done once, which may be better. As a side note, how is one debugging such methods? Looks like the debugger (in 2.0) doesn't like SmallIntegers (I can understand why due to the specific nature of the object but still. Ok, Also VW marks it as a primitive, which Pharo does not. Would we gain some speed doing that? hashMultiply is used a lof for identity hashes. Bytecode has quite some work to do: 37 <70> self 38 <20> pushConstant: 16383 39 <BE> send: bitAnd: 40 <68> popIntoTemp: 0 41 <21> pushConstant: 9741 42 <10> pushTemp: 0 43 <B8> send: * 44 <21> pushConstant: 9741 45 <70> self 46 <22> pushConstant: -14 47 <BC> send: bitShift: 48 <B8> send: * 49 <23> pushConstant: 101 50 <10> pushTemp: 0 51 <B8> send: * 52 <B0> send: + 53 <20> pushConstant: 16383 54 <BE> send: bitAnd: 55 <24> pushConstant: 16384 56 <B8> send: * 57 <B0> send: + 58 <25> pushConstant: 268435455 59 <BE> send: bitAnd: 60 <7C> returnTop I ran some experiments timing things. It looks like that replacing 16384 * by bitShift:14 leads to a small gain, bitShift (primitive 17) being faster than * (primitive 9) The bytecode is identical, except send: bitShift instead of send: * multiplication3 | low | low := self bitAnd: 16383. ^(16r260D * low + ((16r260D * (self bitShift: -14) + (16r0065 * low) bitAnd: 16383) bitShift: 14)) bitAnd: 16r0FFFFFFF [500000 timesRepeat: [ 15000 hashMultiply ]] timeToRun 12 [500000 timesRepeat: [ 15000 multiplication ]] timeToRun 41 (worse) [500000 timesRepeat: [ 15000 multiplication3 ]] timeToRun 10 (better) It looks like correct for SmallInteger minVal to: SmallInteger maxVal Now, VW gives: [500000 timesRepeat: [ 15000 hashMultiply ]] timeToRun 1.149 milliseconds Definitely worth investigating the primitive thing, or some NB Asm as this is used about everywhere (Collections etc). Toughts? Phil

Feb. 25, 2014

Re: [Pharo-dev] [Zinc] Progress bar during download?

by Pavel Krivanek

:-) Thank you, Sven. I realized that sometimes the best hack is to ask :-) Others could find that useful too. Cheers, -- Pavel 2014-02-25 9:37 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Pavel, > > I am surprised that a die hard hacker like you could not find it yourself > ;-) > > Anyway, this is how you do it: > > UIManager default informUserDuring: [ :bar | > [ > ZnClient new > url: ' > http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/27.0/runtimes/xul… > '; > signalProgress: true; > downloadTo: 'xulrunner.zip' ] > on: HTTPProgress > do: [ :progress | > bar label: progress printString. > progress isEmpty ifFalse: [ bar current: progress > percentage ]. > progress resume ] ]. > > First you enable progress signalling, then you catch HTTPProgress and do > something with it. > > Sven > > On 25 Feb 2014, at 09:04, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > Hi, > > > > is there a way how to show progress bar during download of a big files > using #downloadTo: message of the ZnClient? The image is not responsive for > a long time and users may think it's frozen. > > > > example: > > > > ZnClient new url: ' > http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/27.0/runtimes/xul… > '; > > downloadTo: 'xulrunner.zip'. > > > > Cheers, > > -- Pavel > > >

Feb. 25, 2014