- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Ask HN: Examples of elegant, non-trivial Smalltalk? | Hacker News

by Thierry Goubier

Hi Sven, I'd put RB + SmaCC among the lot. But I consider that really non-trivial : the pattern language of RB (and the underlying pattern matching and unification algorithm) is top notch, and how SmaCC builds on RB to virtually generate code / optimise code / then compile is nothing short of amazing. SmaCC comes with a pattern matching/unification algorithm over ASTs + auto-generation of AST code + visitor + tree equality + the equivalent of Flex/Bison(*) + a GUI in 11401 lines of code. Thierry (*) And a true equivalent, with LR, LALR and GLR ! 2016-07-29 14:05 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > <Social Media Marketing> > > The following interesting question/thread could use some more > comments/votes: > > Ask HN: Examples of elegant, non-trivial Smalltalk? | Hacker News > > > https://news.ycombinator.com/item?id=12185892 < > https://news.ycombinator.com/item?id=12185892> > > Sven >

July 29, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50761 Home: https://github.com/pharo-project/pharo-core

July 29, 2016

[pharo-project/pharo-core] fcfdd5: 50761

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: fcfdd5f5d6b21ee6d39951dcf48b242eb1fba0a6 https://github.com/pharo-project/pharo-core/commit/fcfdd5f5d6b21ee6d39951dc… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-07-29 (Fri, 29 Jul 2016) Changed paths: M Network-Mail.package/MailAddressTokenizer.class/class/initialization/initialize.st M Network-Tests.package/MailAddressParserTest.class/instance/tests/testAddressesIn.st A Network-Tests.package/MailAddressParserTest.class/instance/tests/testAmpersand.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50760.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50761.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50760.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50761.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A UnifiedFFI.package/LibC.class/class/fuctions/system_.st Log Message: ----------- 50761 18757 Simple Shell Command Eval for 5.0 https://pharo.fogbugz.com/f/cases/18757 18676 Endless loop parsing e-mail addresses containing an ampersand https://pharo.fogbugz.com/f/cases/18676 http://files.pharo.org/image/50/50761.zip

July 29, 2016

Ask HN: Examples of elegant, non-trivial Smalltalk? | Hacker News

by Sven Van Caekenberghe

<Social Media Marketing> The following interesting question/thread could use some more comments/votes: Ask HN: Examples of elegant, non-trivial Smalltalk? | Hacker News > https://news.ycombinator.com/item?id=12185892 <https://news.ycombinator.com/item?id=12185892> Sven

July 29, 2016

Re: [Pharo-dev] Option for as-in-moose debugger layout

by Denis Kudriashov

2016-07-29 13:28 GMT+02:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > Hi, > > At the integration it was the default but it was changed since more > people found the old way more convenient. > > But I agree it should be a setting :) > I was think that problem was related to Mooc videos which was made with classic debugger look

July 29, 2016

Re: [Pharo-dev] Option for as-in-moose debugger layout

by Cyril Ferlicot D.

Le 27/07/2016 Ã 15:04, Denis Kudriashov a Ã©crit : > I want it too (but I never try it). > > And maybe it is good time to force people taste it as default? (with > setting to return classic one) > Hi, At the integration it was the default but it was changed since more people found the old way more convenient. But I agree it should be a setting :) > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

July 29, 2016

Re: [Pharo-dev] Option for as-in-moose debugger layout

by webwarrior

I second this. Have been using GTDebugger since Pharo3 and always found its layout more convenient. -- View this message in context: http://forum.world.st/Option-for-as-in-moose-debugger-layout-tp4908132p4908… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 29, 2016

Re: [Pharo-dev] [Ann] Remote debugging tools

by Denis Kudriashov

2016-07-29 10:45 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > That sounds wonderful! Thank you very much! Is the new code online? Not yet. Probably I will finish it next week.

July 29, 2016

Re: [Pharo-dev] [Ann] Remote debugging tools

by Norbert Hartl

> Am 29.07.2016 um 10:20 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hi Norbert. > > 2016-07-19 16:11 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > > I see big room for optimizations here. > Look at very small unit of communication: delivering integer result (from [1+2] evaluation). Following object is responsible for this: > > request := SeamlessDeliverResultRequest result: (SeamlessReturnValueResult with: 3) to: (SeamlessRequestContextReference id: 4 peerId: UUID new) . > stream := ByteArray new writeStream. > FLSerializer newDefault serialize: request on: stream. > bytes := stream contents. > bytes size. "==> 412" > (ObjectTraveler on: request ) countReferences "==>10" > > Last line shows that only 10 objects consists full object graph of request. And Fuel serialization takes for it 412 bytes. > It definitely could be improved with specialized serialization protocol. Also it could allow object traversal once which will lead to another performance improvements. > > I start implement optimized protocol and I got really nice results. I reduce size of packet in my example to 16 bytes. I not measure performance yet but it should be better too. Also new protocol will allow application specific optimisations. > So soon we will have really usable tools for your case with slow network. That sounds wonderful! Thank you very much! Is the new code online? Norbert

July 29, 2016

Re: [Pharo-dev] [Ann] Remote debugging tools

by Pavel Krivanek

2016-07-29 10:20 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi Norbert. > > 2016-07-19 16:11 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> I see big room for optimizations here. >> Look at very small unit of communication: delivering integer result (from >> [1+2] evaluation). Following object is responsible for this: >> >> request := SeamlessDeliverResultRequest result: >> (SeamlessReturnValueResult with: 3) to: (SeamlessRequestContextReference >> id: 4 peerId: UUID new) . >> stream := ByteArray new writeStream. >> FLSerializer newDefault serialize: request on: stream. >> bytes := stream contents. >> bytes size. "==> 412" >> (ObjectTraveler on: request ) countReferences "==>10" >> >> >> Last line shows that only 10 objects consists full object graph of >> request. And Fuel serialization takes for it 412 bytes. >> It definitely could be improved with specialized serialization protocol. >> Also it could allow object traversal once which will lead to another >> performance improvements. >> > > I start implement optimized protocol and I got really nice results. I > reduce size of packet in my example to 16 bytes. I not measure performance > yet but it should be better too. Also new protocol will allow application > specific optimisations. > So soon we will have really usable tools for your case with slow network. > Nice!

July 29, 2016