- Pharo-users - lists.pharo.org

Re: [Pharo-users] Attempting Pharo Book #3 WebApp Example on a 64-bit iMac

by Sven Van Caekenberghe

> On 30 Oct 2015, at 01:29, Bruce Prior <b.prior(a)ieee.org> wrote: > > My problem was that I chose a 64-bit Ubuntu OS when I signed up with the ISP, Digital Ocean. So I started another Droplet at DO and set it up with an Ubuntu 32-bit system. > > All is well now and everything down to the end of sec. 12 in Sven's tutorial works for me. Now I'll look at Deploying For Production. Great ! > Many thanks to Sven and Damien for their comments, and to Sven for his fascinating tutorial. Thanks. > Bruce Just for the record, Pharo runs fine in 64-bit, although for the moment it remains a 32-bit application. There are various ways to install the VM. If you follow my approach using the zero config scripts, and you only need to deploy to a headless server, the following script installs what is needed on Ubuntu: https://github.com/svenvc/pharo-server-tools/blob/master/ubuntu-32bit-suppo… Sven

Oct. 30, 2015

Attempting Pharo Book #3 WebApp Example on a 64-bit iMac

by Bruce Prior

My problem was that I chose a 64-bit Ubuntu OS when I signed up with the ISP, Digital Ocean. So I started another Droplet at DO and set it up with an Ubuntu 32-bit system. All is well now and everything down to the end of sec. 12 in Sven's tutorial works for me. Now I'll look at Deploying For Production. Many thanks to Sven and Damien for their comments, and to Sven for his fascinating tutorial. Bruce

Oct. 30, 2015

Re: [Pharo-users] What is your preferred way for storing ByteArray's as text?

by Esteban A. Maringolo

2015-10-29 17:59 GMT-03:00 Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com>: > On Thu, Oct 29, 2015 at 5:18 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: >> >> 2015-10-29 17:07 GMT-03:00 Bernardo Ezequiel Contreras >> <vonbecmann(a)gmail.com>: >> > Esteban, >> > Could you explain line 8 ? why did you use a Base64MimeConverter? >> > thanks. >> > >> > line 8: >> > >> > stream nextPutAll: 'ZnBase64Encoder '; nextPutAll: [ >> > (Base64MimeConverter >> > mimeEncode: ba readStream multiLine: false) ] bench printString; cr. >> >> Because it is the class used by ByteArray>>#base64Encoded. > thanks, so the title should be Base64MimeConverter instead of > ZnBase64Encoder. No... I got it wrong, it was a copy & paste mistake. It should be Zn... because I put them both in the tests to compare. Thank you for noticing. Regards! Esteban A. Maringolo

Oct. 29, 2015

Re: [Pharo-users] What is your preferred way for storing ByteArray's as text?

by Bernardo Ezequiel Contreras

thanks, so the title should be Base64MimeConverter instead of ZnBase64Encoder. On Thu, Oct 29, 2015 at 5:18 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2015-10-29 17:07 GMT-03:00 Bernardo Ezequiel Contreras < > vonbecmann(a)gmail.com>: > > Esteban, > > Could you explain line 8 ? why did you use a Base64MimeConverter? > > thanks. > > > > line 8: > > > > stream nextPutAll: 'ZnBase64Encoder '; nextPutAll: [ (Base64MimeConverter > > mimeEncode: ba readStream multiLine: false) ] bench printString; cr. > > Because it is the class used by ByteArray>>#base64Encoded. > > Esteban A. Maringolo > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Oct. 29, 2015

Re: [Pharo-users] What is your preferred way for storing ByteArray's as text?

by Esteban A. Maringolo

2015-10-29 17:07 GMT-03:00 Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com>: > Esteban, > Could you explain line 8 ? why did you use a Base64MimeConverter? > thanks. > > line 8: > > stream nextPutAll: 'ZnBase64Encoder '; nextPutAll: [ (Base64MimeConverter > mimeEncode: ba readStream multiLine: false) ] bench printString; cr. Because it is the class used by ByteArray>>#base64Encoded. Esteban A. Maringolo

Oct. 29, 2015

Re: [Pharo-users] What is your preferred way for storing ByteArray's as text?

by Bernardo Ezequiel Contreras

Esteban, Could you explain line 8 ? why did you use a Base64MimeConverter? thanks. line 8: stream nextPutAll: 'ZnBase64Encoder '; nextPutAll: [ (Base64MimeConverter mimeEncode: ba readStream multiLine: false) ] bench printString; cr. On Thu, Oct 29, 2015 at 3:43 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2015-10-29 15:21 GMT-03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> >>> Option A) The printString of ByteArray, it is #[23 12 253 ...] > >> > >> >>> Option B) A Base64 encoded version of the ByteArray > > > > > > I like this one, because it is not Pharo-specific format. ByteArray is > not > > pharo-specific, but the syntax is --- I can copy paste base64 from/to > > outside world. > > Plus base64 has better tool support in the wild. > > I also prefer base64 even over native binary storage. > > I ran a small comparison[1] of speed and size and these were my results. > > ByteArray size: 19448860 > > Speed: > Base64MimeConverter: ''0.592 per second'' > #hex: ''0.666 per second'' > #asString: ''6.898 per second'' > ZnBase64Encoder ''0.459 per second'' > > Size: > Base64MimeConverter: 26291980 > #hex: 38897720 > #asString: 19448860 > ZnBase64Encoder 25931816 > > Esteban A. Maringolo > > [1]: http://ws.stfx.eu/47PV2GUP9ITS > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Oct. 29, 2015

Re: [Pharo-users] What is your preferred way for storing ByteArray's as text?

by Esteban A. Maringolo

2015-10-29 15:21 GMT-03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> >>> Option A) The printString of ByteArray, it is #[23 12 253 ...] >> >> >>> Option B) A Base64 encoded version of the ByteArray > > > I like this one, because it is not Pharo-specific format. ByteArray is not > pharo-specific, but the syntax is --- I can copy paste base64 from/to > outside world. > Plus base64 has better tool support in the wild. I also prefer base64 even over native binary storage. I ran a small comparison[1] of speed and size and these were my results. ByteArray size: 19448860 Speed: Base64MimeConverter: ''0.592 per second'' #hex: ''0.666 per second'' #asString: ''6.898 per second'' ZnBase64Encoder ''0.459 per second'' Size: Base64MimeConverter: 26291980 #hex: 38897720 #asString: 19448860 ZnBase64Encoder 25931816 Esteban A. Maringolo [1]: http://ws.stfx.eu/47PV2GUP9ITS

Oct. 29, 2015

Re: [Pharo-users] What is your preferred way for storing ByteArray's as text?

by Peter UhnÃ¡k

> > >>> Option A) The printString of ByteArray, it is #[23 12 253 ...] >>> Option B) A Base64 encoded version of the ByteArray > I like this one, because it is not Pharo-specific format. ByteArray is not pharo-specific, but the syntax is --- I can copy paste base64 from/to outside world. Plus base64 has better tool support in the wild.

Oct. 29, 2015

Re: [Pharo-users] How to add a keyboard shortcut to Rubric?

by Johan Fabry

Excellent Nicolai, thanks for the detailed answer! Now I have everything working exactly as I want it to be, so Iâm happy :-) (Also, alex, thanks for pointing out the tab in the inspector, but I think I would have not found it since the morph is embedded in a Spec window so it would have been even deeper in the hierarchy.) > On Oct 28, 2015, at 20:04, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2015-10-28 23:56 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>>: > You can use the power of Inspector! Inspect rubric morph and you will see there is shortcuts tab which lists all assigned shortcuts and if you click on one them a new tab will be opened to the right showing exact place in source code when shortcut is defined and its action. > > > This does not really help if you don't know which morph actually gets the shortcut definitions. > In my example I did the same mistake, even if you instantiate a RubScrolledTextMORPH the object > that processes the keyevents is actually a RubEditingArea, accessible through > (RubScollredTextMorph) self textArea. ( if you are working with a spec TextModel this you need to call it two times > > t:= TextModel new. > "the textarea is: " > t textArea textArea " : - (" > > > On Oct 28, 2015 11:05 PM, "Johan Fabry" <jfabry(a)dcc.uchile.cl <mailto:jfabry@dcc.uchile.cl>> wrote: > Hi Nicolai, > > thanks for your answer! However, apparently the problem is a bit different: the shortcut I wanted to add, cmd-s, already existed but I did not realize it! I want to add cmd-s to save the text to a file, but the editor has auto accept set to true and cmd-s calls accept by default. So adding another cmd-s did not do anything and neither could I see that the existing cmd-s binding was executing some other behavior :-/ > > After seeing this, I expected that I would be able to remove the cmd-s keybinding, using removeKeyCombination: but apparently I cannot (see example below). > > In general, itâs not nice to discover from the code that there are keyboard shortcuts that are not listed in the context menu. The enduser should be able to discover all active keybindings from what is visible in the UI and this is not the case here. Maybe Iâll make a subclass of RubTextEditor that only reimplements buildShortcutsOn: so that it is without all these hidden keybindings. > > But for now Iâll add cmd-d to do save â¦ although thatâs ugly. :-( > > | window text | > text := RubScrolledTextMorph new. > > "define a custom shortcut" > text removeKeyCombination: $s command. > text on:$s command do:[ > text setText: text text asString reverse]. > > window := StandardWindow new. > window addMorph: text fullFrame: (0@0 corner: 1@1) asLayoutFrame. > window title: 'Example'. > window openInWorld. > > @Johan, as above, the "correct" morph for processing the keyevents is the textArea of the RubScrolledTextMorph, > this should work > > > | window text | > text := RubScrolledTextMorph new. > > "define a custom shortcut - notice the call to textArea" > > text textArea removeKeyCombination: $s command. > text textArea on:$s command do:[ > text setText: text text asString reverse]. > > window := StandardWindow new. > window addMorph: text fullFrame: (0@0 corner: 1@1) asLayoutFrame. > window title: 'Example'. > window openInWorld. > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Oct. 29, 2015

Re: [Pharo-users] fast subclassing/class creation in tests

by Peter UhnÃ¡k

> > yes, I already felt that test runs involving unlogged code generation is > very slowâ¦ can you add an entry on the issue tracker? > I can, but I am not sure for what. :) a) speed up regular class operations (class creation, removal, compilation) b) speed up unlogged class ops c) modify code generation tests in Pharo (ClassTest, possibly others) to use unlogged/suspendAllWhile d) all of the above (as separate issues) plus bonus e) create classes/methods without polluting the environment (.changes file) (because only removal is unlogged, not creation) (if this is even possible) Peter

Oct. 29, 2015