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

[pharo-project/pharo-core] d2393b: 50155

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: d2393b18d36f124692a5d4d149d723877f08f74a https://github.com/pharo-project/pharo-core/commit/d2393b18d36f124692a5d4d1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-07-06 (Mon, 06 Jul 2015) Changed paths: M ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/symbolic versions/stable_.st A ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/versions/version073_.st R Morphic-Widgets-FastTable.package/FTPluggableIconListMorphAdaptor.class/class/accessing/defaultRowHeight.st M Morphic-Widgets-FastTable.package/FTPluggableIconListMorphAdaptor.class/instance/ignored/searchedElement_.st A Morphic-Widgets-FastTable.package/FTPluggableIconListMorphAdaptor.class/instance/updating/basicUpdateSelectionIndex.st M Morphic-Widgets-FastTable.package/FTPluggableIconListMorphAdaptor.class/instance/updating/updateList.st M Morphic-Widgets-FastTable.package/FTPluggableIconListMorphAdaptor.class/instance/updating/updateSelectionIndex.st M Morphic-Widgets-FastTable.package/FTSelectionStrategy.class/instance/private/toggleRowIndex_.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/drawing/fullDrawOn_.st A Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/private/calculateColumnWidths.st A Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/testing/canRefreshValues.st R Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/updating/calculateColumnWidths.st R Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/updating/calculateExposedRows.st R Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/updating/calculateHeaderRow.st R Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/updating/canRefreshValues.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/updating/changed.st A Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/updating/updateAllRows.st A Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/updating/updateExposedRows.st A Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/updating/updateHeaderRow.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/class/accessing/defaultRowHeight.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing selection/highlightRowIndexes_.st A Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing selection/highlightedRowIndex.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/event handling/keyStroke_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/event testing/takesKeyboardFocus.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/private/recalculateVerticalScrollBar.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/private/recalculateVerticalScrollBarVisibilityIfHidden_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/private/verticalScrollBarValueToRowIndex_.st A Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/testing/hasHighlighted.st A Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/testing/isRowIndexVisible_.st M Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertMethodWidget.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertMethodWidgetAdaptor.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertMethodWidgetPluggableListMorph.st M Nautilus.package/NautilusUI.class/instance/displaying/open.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50154.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50155.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50154.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50155.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50155 15904 fast table need to react better to selections and searches https://pharo.fogbugz.com/f/cases/15904 15894 nautilus need to take into account the new fast table when selecting and testing https://pharo.fogbugz.com/f/cases/15894 http://files.pharo.org/image/50/50155.zip

July 6, 2015

Re: [Pharo-dev] Getting the mbox file for this mailing list?

by Dmitri Zagidulin

Sven - thanks! I'll try those. Oh, and as far as having to log in first, apparently you can pass in your username and password as a part of the url. So, the generic template would be: ' http://www.example.com/mailman/private/LIST.mbox/LIST.mbox?username=U&passw… ' On Mon, Jul 6, 2015 at 10:15 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > With ZnHeaders and ZnMimePart you should get a long way in parsing mail > boxes. I believe some people have already experimented with this, but I am > not sure and I forgot. > > > On 06 Jul 2015, at 16:11, Dmitri Zagidulin <dmitri(a)zagidulin.net> wrote: > > > > I've been doing some mailing list analysis recently (in Ruby), and would > be very interested in porting it over to Smalltalk. (I was actually getting > really frustrated at the lack of proper debugging setup in Ruby, even > though it had some great mail-related libraries). I was looking at thread > lengths, numbers of unanswered threads, etc. > > > > Alexandre -- I haven't been able to find a good Mail parsing library for > Smalltalk (preferably one that reads the Mbox format natively), I'd be > curious to know what you end up using. > > > > As for the download URL -- the link Marcus gave is, unfortunately, in > Piper-mail's own format (a simplified version of mbox, really). > > To get the actual .mbox file, you'd need to use this link: > > > > > http://lists.pharo.org/mailman/private/pharo-dev_lists.pharo.org.mbox/pharo… > > > > (Note that it requires you to authenticate with your mailing list email > and password (that you created when you first signed up for the mailing > list)). But once authenticated, you can download it with Zinc (or wget) or > whatever, and start processing it. > > > > Let us know how it goes! > > > > > > On Mon, Jul 6, 2015 at 8:41 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > > > > > > 2015-07-06 14:29 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > > The archives are straight text files, in which the individual messages > are > > separated by a seemingly random number of LFs. > > > > Actually they are valid mbox files. (At least my mutt opened it just > fine.) > > The separator is "From " line, not newlines. > > > > From followed by a space. Each message ends with an blank line > > > > https://en.wikipedia.org/wiki/Mbox, https://tools.ietf.org/html/rfc4155 > > > > It seems there are multiple, incompatible mbox formats. > > > > Thierry > > > > > > >

July 6, 2015

Re: [Pharo-dev] Getting the mbox file for this mailing list?

by Sven Van Caekenberghe

With ZnHeaders and ZnMimePart you should get a long way in parsing mail boxes. I believe some people have already experimented with this, but I am not sure and I forgot. > On 06 Jul 2015, at 16:11, Dmitri Zagidulin <dmitri(a)zagidulin.net> wrote: > > I've been doing some mailing list analysis recently (in Ruby), and would be very interested in porting it over to Smalltalk. (I was actually getting really frustrated at the lack of proper debugging setup in Ruby, even though it had some great mail-related libraries). I was looking at thread lengths, numbers of unanswered threads, etc. > > Alexandre -- I haven't been able to find a good Mail parsing library for Smalltalk (preferably one that reads the Mbox format natively), I'd be curious to know what you end up using. > > As for the download URL -- the link Marcus gave is, unfortunately, in Piper-mail's own format (a simplified version of mbox, really). > To get the actual .mbox file, you'd need to use this link: > > http://lists.pharo.org/mailman/private/pharo-dev_lists.pharo.org.mbox/pharo… > > (Note that it requires you to authenticate with your mailing list email and password (that you created when you first signed up for the mailing list)). But once authenticated, you can download it with Zinc (or wget) or whatever, and start processing it. > > Let us know how it goes! > > > On Mon, Jul 6, 2015 at 8:41 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-07-06 14:29 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > The archives are straight text files, in which the individual messages are > separated by a seemingly random number of LFs. > > Actually they are valid mbox files. (At least my mutt opened it just fine.) > The separator is "From " line, not newlines. > > From followed by a space. Each message ends with an blank line > > https://en.wikipedia.org/wiki/Mbox, https://tools.ietf.org/html/rfc4155 > > It seems there are multiple, incompatible mbox formats. > > Thierry > >

July 6, 2015

Re: [Pharo-dev] Getting the mbox file for this mailing list?

by Dmitri Zagidulin

I've been doing some mailing list analysis recently (in Ruby), and would be very interested in porting it over to Smalltalk. (I was actually getting really frustrated at the lack of proper debugging setup in Ruby, even though it had some great mail-related libraries). I was looking at thread lengths, numbers of unanswered threads, etc. Alexandre -- I haven't been able to find a good Mail parsing library for Smalltalk (preferably one that reads the Mbox format natively), I'd be curious to know what you end up using. As for the download URL -- the link Marcus gave is, unfortunately, in Piper-mail's own format (a simplified version of mbox, really). To get the actual .mbox file, you'd need to use this link: http://lists.pharo.org/mailman/private/pharo-dev_lists.pharo.org.mbox/pharo… (Note that it requires you to authenticate with your mailing list email and password (that you created when you first signed up for the mailing list)). But once authenticated, you can download it with Zinc (or wget) or whatever, and start processing it. Let us know how it goes! On Mon, Jul 6, 2015 at 8:41 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-07-06 14:29 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> The archives are straight text files, in which the individual messages are >>> separated by a seemingly random number of LFs. >> >> >> Actually they are valid mbox files. (At least my mutt opened it just >> fine.) >> The separator is "From " line, not newlines. >> > > From followed by a space. Each message ends with an blank line > > https://en.wikipedia.org/wiki/Mbox, https://tools.ietf.org/html/rfc4155 > > It seems there are multiple, incompatible mbox formats. > > Thierry > >

July 6, 2015

Re: [Pharo-dev] Musings (Was: NAtiveBoost error)

by Kjell Godo

i cannot seem to find this generator package on SmalltalkHub and i wonder where it could be On Monday, July 6, 2015, Kjell Godo <squeaklist(a)gmail.com> wrote: > Object Orientation > > seems to freak out most Haskell programmers. > > They are opposed to it. They have never tried Smalltalk. > > They see OOP as bad practice in the languages they have seen it in > > and say it promotes chaotic program behaviour and unmaintainable software > > that is brittle and full of costly bugs. They have never tried > Smalltalk and some > > are a bit bewildered when i say Smalltalk is usually very stable. > > > > i just wonder if > > functional state management > > would make Smalltalk development > > faster and less Chaotic > > and how you could marry OOP and functional > > and if you did then how would you do it > > > > how can the concepts of functional and OOP be combined > > > > is my question > > > > what are all the concepts and how can they be combined > > > > > because i do think that perhaps Smalltalk development is slowed down > > and made more Chaotic and unmaintainable by mutable data in Objects > > > > so in order to correct this in my opinion > > the first step > > would be to create immutable Objects > > > > my Generator package i published for Pharo > > is perhaps an example of how immutable sequences can be done in Smalltalk > > but the basic idea is that > > you create new Objects that link into the pieces of old ones > > instead of mutating the old ones > > no instance variables can be rebound once they have been bound > > > > > ok so this boggles the mind a bit > > but they swear by it in Haskell > > so > > what exactly are the Haskellers talking about? > > and can it be applied to Smalltalk to Smalltalk's benefit? > > > > > > On Monday, July 6, 2015, Kjell Godo <squeaklist(a)gmail.com > <javascript:_e(%7B%7D,'cvml','squeaklist(a)gmail.com');>> wrote: > >> Thank you for the detailed reply Andreas >> >> >> >> Are there any Smalltalk packages implementing >> >> Category Theory based >> >> functional programming constructs >> >> for function composition like >> >> functors , applicatives , monads , arrows , etc ? >> >> >> >> Do people have opinions about whether or not >> >> these plus immutable data structures would be good for managing state >> >> in Smalltalk like they do it in Haskell etc? i know that monads are not >> built >> >> into Haskell but are implemented as addons via Haskell packages. >> >> My Haskell friend said all you need to do functional programming is >> >> first class functions >> >> which Smalltalk Block contexts almost are except they lack their own >> stack? >> >> if you wrap a Block in a Function Object do you then get the stack >> >> effect so you can essentially call the Block recursively? >> >> >> >> i have been wondering about taking a crack at implementing these >> >> in Smalltalk and i wonder if it would be >> >> theoretically possible >> >> to speed them up by inlining them via the Smalltalk compiler >> >> >> Thank you >> >> >> >> On Saturday, November 8, 2014, Andreas Wacknitz <a.wacknitz(a)gmx.de> >> wrote: >> >>> >>> Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist(a)gmail.com>: >>> >>> This is off topic. >>> >>> I tried to post it as a top level thread but I have become unknown. >>> >>> Why do you expect that? Many people here are using Smalltalk for years. >>> Just because you have been silent for some time doesnât mean everybody >>> will forget about you :) >>> >>> >>> I don't know if you want this crap in here but I have decided not to >>> wait for the >>> >>> postmaster to get back to me on the subject of becoming known. Feel >>> free. >>> >>> >>> >>> >>> >>> ( Original-SUBJECT: "( picoVerse-:( what about state , is state >>> really evil? ) )" ) >>> >>> >>> >>> >>> >>> >>> I am a Smalltalker. >>> >>> But in the past few months i have been running with the Haskellers. >>> >>> The Haskellers hate state. >>> >>> This seemed strange at first because as a Smalltalker i love(d) state. >>> State iswas my friend. >>> >>> 90% of my life as a Smalltalker is state wrangling. I am a state >>> herder. >>> >>> The debugger is my staff I use to whack the state. And TestCase is my >>> sheep dog. >>> >>> But to the Haskellers >>> >>> state is >>> >>> the evil trinity >>> >>> of >>> >>> satan the anti christ and the false prophet >>> >>> all rolled into one. >>> >>> State is the true dev incarnation of the total catastrophe of >>> development Armageddon. >>> >>> Blood up to the bridles for hundreds of miles. Dogs and cats living >>> together. Mass hysteria. >>> >>> They say. >>> >>> I'm not sure i quite get it yet but they keep preaching on this one >>> point most of all. >>> >>> State is evil. >>> >>> You must keep all state in a Monad. As many methods/functions m as >>> possible >>> >>> must be 100% dependent on the input parameters ONLY. >>> >>> No hidden instance variables affecting the return value of m are allowed. >>> >>> The only effect m can have is to return a value. >>> >>> If all this is true then m is pure. >>> >>> And pure is good. Pure is very good. And the wind says >>> >>> very. >>> >>> So i wonder if any of you fellow >>> >>> Smalltalkers >>> >>> have thought about this at all. >>> >>> First, there are no good definitions of what is an object oriented >>> language and what is a functional language. >>> Thus, languages like C++, C#, Java are being considered object oriented. >>> But their object orientation is not the same like Smalltalkâs. >>> The same problem exists in the functional language world: Some consider >>> LISP being functional, some deny that. >>> >>> Second, for some years I am constantly seeking for âthe bestâ language >>> to solve my problems in. Alas I wasnât successful yet and donât expect >>> to be successful in the future. Every programming paradigm has its >>> strengths and weaknesses when it comes to real world problems. >>> So in my eyes it is best to know the different programming paradigms and >>> its representative languages in order to be able to choose the >>> best fitting language for your problem at hand. >>> >>> Third, there have been many attempts to create multi-paradigm languages >>> (like C++, C#, Java, Scala, â¦). The idea behind is simple: combine >>> the best characteristics. In my eyes all of them failed because what >>> always have been created is Frankensteinâs monster. When you combine >>> paradigms you will may get some advantages of all but sure you will get >>> a lot of additional complexity. >>> >>> Fourth, it has been said many times before: What makes Smalltalk so nice >>> is not only the language. Itâs the whole system: the language, duck typing, >>> the image (object world), the tools, the VM, the simplicity, the >>> elegance, â¦ And last but not least the communities around. >>> >>> Regards >>> Andreas >>> >>> PS: If you are interested in functional programming and donât like >>> static typing you should have a look at Clojure. It has some nice ideas >>> about >>> how to deal with state concurrently. >>> >>> >>> >>> Thanks >>> >>> Kjell E GodÃ¸ >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> (((((((((( Maybe Smalltalk should be called Statewalk >>> >>> as in yak it up fuzz ball. )))))))))) >>> >>> >>>

July 6, 2015

Re: [Pharo-dev] Musings (Was: NAtiveBoost error)

by Kjell Godo

Object Orientation seems to freak out most Haskell programmers. They are opposed to it. They have never tried Smalltalk. They see OOP as bad practice in the languages they have seen it in and say it promotes chaotic program behaviour and unmaintainable software that is brittle and full of costly bugs. They have never tried Smalltalk and some are a bit bewildered when i say Smalltalk is usually very stable. i just wonder if functional state management would make Smalltalk development faster and less Chaotic and how you could marry OOP and functional and if you did then how would you do it how can the concepts of functional and OOP be combined is my question what are all the concepts and how can they be combined because i do think that perhaps Smalltalk development is slowed down and made more Chaotic and unmaintainable by mutable data in Objects so in order to correct this in my opinion the first step would be to create immutable Objects my Generator package i published for Pharo is perhaps an example of how immutable sequences can be done in Smalltalk but the basic idea is that you create new Objects that link into the pieces of old ones instead of mutating the old ones no instance variables can be rebound once they have been bound ok so this boggles the mind a bit but they swear by it in Haskell so what exactly are the Haskellers talking about? and can it be applied to Smalltalk to Smalltalk's benefit? On Monday, July 6, 2015, Kjell Godo <squeaklist(a)gmail.com> wrote: > Thank you for the detailed reply Andreas > > > > Are there any Smalltalk packages implementing > > Category Theory based > > functional programming constructs > > for function composition like > > functors , applicatives , monads , arrows , etc ? > > > > Do people have opinions about whether or not > > these plus immutable data structures would be good for managing state > > in Smalltalk like they do it in Haskell etc? i know that monads are not > built > > into Haskell but are implemented as addons via Haskell packages. > > My Haskell friend said all you need to do functional programming is > > first class functions > > which Smalltalk Block contexts almost are except they lack their own stack? > > if you wrap a Block in a Function Object do you then get the stack > > effect so you can essentially call the Block recursively? > > > > i have been wondering about taking a crack at implementing these > > in Smalltalk and i wonder if it would be > > theoretically possible > > to speed them up by inlining them via the Smalltalk compiler > > > Thank you > > > > On Saturday, November 8, 2014, Andreas Wacknitz <a.wacknitz(a)gmx.de > <javascript:_e(%7B%7D,'cvml','a.wacknitz(a)gmx.de');>> wrote: > >> >> Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist(a)gmail.com>: >> >> This is off topic. >> >> I tried to post it as a top level thread but I have become unknown. >> >> Why do you expect that? Many people here are using Smalltalk for years. >> Just because you have been silent for some time doesnât mean everybody >> will forget about you :) >> >> >> I don't know if you want this crap in here but I have decided not to wait >> for the >> >> postmaster to get back to me on the subject of becoming known. Feel free. >> >> >> >> >> >> ( Original-SUBJECT: "( picoVerse-:( what about state , is state >> really evil? ) )" ) >> >> >> >> >> >> >> I am a Smalltalker. >> >> But in the past few months i have been running with the Haskellers. >> >> The Haskellers hate state. >> >> This seemed strange at first because as a Smalltalker i love(d) state. >> State iswas my friend. >> >> 90% of my life as a Smalltalker is state wrangling. I am a state herder. >> >> >> The debugger is my staff I use to whack the state. And TestCase is my >> sheep dog. >> >> But to the Haskellers >> >> state is >> >> the evil trinity >> >> of >> >> satan the anti christ and the false prophet >> >> all rolled into one. >> >> State is the true dev incarnation of the total catastrophe of development >> Armageddon. >> >> Blood up to the bridles for hundreds of miles. Dogs and cats living >> together. Mass hysteria. >> >> They say. >> >> I'm not sure i quite get it yet but they keep preaching on this one point >> most of all. >> >> State is evil. >> >> You must keep all state in a Monad. As many methods/functions m as >> possible >> >> must be 100% dependent on the input parameters ONLY. >> >> No hidden instance variables affecting the return value of m are allowed. >> >> The only effect m can have is to return a value. >> >> If all this is true then m is pure. >> >> And pure is good. Pure is very good. And the wind says >> >> very. >> >> So i wonder if any of you fellow >> >> Smalltalkers >> >> have thought about this at all. >> >> First, there are no good definitions of what is an object oriented >> language and what is a functional language. >> Thus, languages like C++, C#, Java are being considered object oriented. >> But their object orientation is not the same like Smalltalkâs. >> The same problem exists in the functional language world: Some consider >> LISP being functional, some deny that. >> >> Second, for some years I am constantly seeking for âthe bestâ language to >> solve my problems in. Alas I wasnât successful yet and donât expect >> to be successful in the future. Every programming paradigm has its >> strengths and weaknesses when it comes to real world problems. >> So in my eyes it is best to know the different programming paradigms and >> its representative languages in order to be able to choose the >> best fitting language for your problem at hand. >> >> Third, there have been many attempts to create multi-paradigm languages >> (like C++, C#, Java, Scala, â¦). The idea behind is simple: combine >> the best characteristics. In my eyes all of them failed because what >> always have been created is Frankensteinâs monster. When you combine >> paradigms you will may get some advantages of all but sure you will get a >> lot of additional complexity. >> >> Fourth, it has been said many times before: What makes Smalltalk so nice >> is not only the language. Itâs the whole system: the language, duck typing, >> the image (object world), the tools, the VM, the simplicity, the >> elegance, â¦ And last but not least the communities around. >> >> Regards >> Andreas >> >> PS: If you are interested in functional programming and donât like static >> typing you should have a look at Clojure. It has some nice ideas about >> how to deal with state concurrently. >> >> >> >> Thanks >> >> Kjell E GodÃ¸ >> >> >> >> >> >> >> >> >> >> (((((((((( Maybe Smalltalk should be called Statewalk >> >> as in yak it up fuzz ball. )))))))))) >> >> >>

July 6, 2015

Re: [Pharo-dev] Musings (Was: NAtiveBoost error)

by Eliot Miranda

Hi Kjell, On Jul 6, 2015, at 6:16 AM, Kjell Godo <squeaklist(a)gmail.com> wrote: > Thank you for the detailed reply Andreas > > > > Are there any Smalltalk packages implementing > > Category Theory based > > functional programming constructs > > for function composition like > > functors , applicatives , monads , arrows , etc ? > > > > Do people have opinions about whether or not > > these plus immutable data structures would be good for managing state > > in Smalltalk like they do it in Haskell etc? i know that monads are not built > > into Haskell but are implemented as addons via Haskell packages. > > My Haskell friend said all you need to do functional programming is > > first class functions > > which Smalltalk Block contexts almost are except they lack their own stack? > > if you wrap a Block in a Function Object do you then get the stack > > effect so you can essentially call the Block recursively? The Pharo & Squeak dialects, along with most others, now have closures, so blocks are fully recursive. > > i have been wondering about taking a crack at implementing these > > in Smalltalk and i wonder if it would be > > theoretically possible > > to speed them up by inlining them via the Smalltalk compiler The compiler already inlines closures in a few key control messages such as ifTrue: whileTrue: and:. I recommend spending some time reading the code for the core execution classes and the compiler, and running examples interactively to learn how the system works. It's a fun process and well supported by the tools. Remember that the debugger includes a meta circular interpreter for executing the system's bytecode, and that the compiler compiles source to bytecode in the firm of CompiledMethod instances you can inspect, decompile and list their bytecode. All the questions you have above you can answer for yourself by running examples and using the tools to observe what happens. This is a route to mastering the system; IMNERHO the best. > Thank you Eliot (phone) > On Saturday, November 8, 2014, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: >> >>> Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist(a)gmail.com>: >>> >>> This is off topic. >>> >>> I tried to post it as a top level thread but I have become unknown. >> Why do you expect that? Many people here are using Smalltalk for years. >> Just because you have been silent for some time doesnât mean everybody will forget about you :) >> >>> >>> I don't know if you want this crap in here but I have decided not to wait for the >>> >>> postmaster to get back to me on the subject of becoming known. Feel free. >>> >>> >>> >>> >>> >>> ( Original-SUBJECT: "( picoVerse-:( what about state , is state really evil? ) )" ) >>> >>> >>> >>> >>> >>> >>> I am a Smalltalker. >>> >>> But in the past few months i have been running with the Haskellers. >>> >>> The Haskellers hate state. >>> >>> This seemed strange at first because as a Smalltalker i love(d) state. State iswas my friend. >>> >>> 90% of my life as a Smalltalker is state wrangling. I am a state herder. >>> >>> The debugger is my staff I use to whack the state. And TestCase is my sheep dog. >>> >>> But to the Haskellers >>> >>> state is >>> >>> the evil trinity >>> >>> of >>> >>> satan the anti christ and the false prophet >>> >>> all rolled into one. >>> >>> State is the true dev incarnation of the total catastrophe of development Armageddon. >>> >>> Blood up to the bridles for hundreds of miles. Dogs and cats living together. Mass hysteria. >>> >>> They say. >>> >>> I'm not sure i quite get it yet but they keep preaching on this one point most of all. >>> >>> State is evil. >>> >>> You must keep all state in a Monad. As many methods/functions m as possible >>> >>> must be 100% dependent on the input parameters ONLY. >>> >>> No hidden instance variables affecting the return value of m are allowed. >>> >>> The only effect m can have is to return a value. >>> >>> If all this is true then m is pure. >>> >>> And pure is good. Pure is very good. And the wind says >>> >>> very. >>> >>> So i wonder if any of you fellow >>> >>> Smalltalkers >>> >>> have thought about this at all. >> >> First, there are no good definitions of what is an object oriented language and what is a functional language. >> Thus, languages like C++, C#, Java are being considered object oriented. But their object orientation is not the same like Smalltalkâs. >> The same problem exists in the functional language world: Some consider LISP being functional, some deny that. >> >> Second, for some years I am constantly seeking for âthe bestâ language to solve my problems in. Alas I wasnât successful yet and donât expect >> to be successful in the future. Every programming paradigm has its strengths and weaknesses when it comes to real world problems. >> So in my eyes it is best to know the different programming paradigms and its representative languages in order to be able to choose the >> best fitting language for your problem at hand. >> >> Third, there have been many attempts to create multi-paradigm languages (like C++, C#, Java, Scala, â¦). The idea behind is simple: combine >> the best characteristics. In my eyes all of them failed because what always have been created is Frankensteinâs monster. When you combine >> paradigms you will may get some advantages of all but sure you will get a lot of additional complexity. >> >> Fourth, it has been said many times before: What makes Smalltalk so nice is not only the language. Itâs the whole system: the language, duck typing, >> the image (object world), the tools, the VM, the simplicity, the elegance, â¦ And last but not least the communities around. >> >> Regards >> Andreas >> >> PS: If you are interested in functional programming and donât like static typing you should have a look at Clojure. It has some nice ideas about >> how to deal with state concurrently. >> >> >> >>> Thanks >>> >>> Kjell E GodÃ¸ >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> (((((((((( Maybe Smalltalk should be called Statewalk >>> >>> as in yak it up fuzz ball. ))))))))))

July 6, 2015

Re: [Pharo-dev] Control Flow Graph for Smalltalk

by Francisco Garau

Hi Nevena To compute the control flow graph you would need to do concrete type inference. Search for Ole Agesen PhD thesis to have an idea what's that about. I've started a smalltalk implementation of his ideas in 2001 but never got beyond the proof of concept stage. I can forward the presentation slides later tonight. Cheers - Francisco > On 6 Jul 2015, at 12:21, Nevena Milojkovic <nevena(a)iam.unibe.ch> wrote: > > Hi all, > > Can anybody point me towards some tool/paper with the possibility to construct Control Flow Graph for Smalltalk? > > Cheers, > Nevena > > ââââââââ > Nevena Milojkovic > Research assistant > Software Composition Group > Institute of Computer Science and Applied Mathematics > University of Bern > > email: nevena(a)iam.unibe.ch > office phone: +41 (0)31 511 7639 > webpage: http://scg.unibe.ch/staff/Milojkovic > > > > > >

July 6, 2015

Re: [Pharo-dev] Musings (Was: NAtiveBoost error)

by Sven Van Caekenberghe

> On 06 Jul 2015, at 15:16, Kjell Godo <squeaklist(a)gmail.com> wrote: > > Thank you for the detailed reply Andreas > > > > Are there any Smalltalk packages implementing > > Category Theory based > > functional programming constructs > > for function composition like > > functors , applicatives , monads , arrows , etc ? > > > > Do people have opinions about whether or not > > these plus immutable data structures would be good for managing state > > in Smalltalk like they do it in Haskell etc? i know that monads are not built > > into Haskell but are implemented as addons via Haskell packages. > > My Haskell friend said all you need to do functional programming is > > first class functions > > which Smalltalk Block contexts almost are except they lack their own stack? > > if you wrap a Block in a Function Object do you then get the stack > > effect so you can essentially call the Block recursively? The following article: Lambda Calculus in Pharo Yes, the Y Combinator is useful in normal programs https://medium.com/concerning-pharo/lambda-calculus-in-pharo-a4a571869594 touches on some of the options in this area, answering some of your questions. TL;DR - Pharo blocks are real lambdas/closures. > i have been wondering about taking a crack at implementing these > > in Smalltalk and i wonder if it would be > > theoretically possible > > to speed them up by inlining them via the Smalltalk compiler > > > Thank you > > > > On Saturday, November 8, 2014, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: > >> Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist(a)gmail.com>: >> >> This is off topic. >> >> I tried to post it as a top level thread but I have become unknown. > Why do you expect that? Many people here are using Smalltalk for years. > Just because you have been silent for some time doesnât mean everybody will forget about you :) > >> >> I don't know if you want this crap in here but I have decided not to wait for the >> >> postmaster to get back to me on the subject of becoming known. Feel free. >> >> >> >> >> >> ( Original-SUBJECT: "( picoVerse-:( what about state , is state really evil? ) )" ) >> >> >> >> >> >> >> I am a Smalltalker. >> >> But in the past few months i have been running with the Haskellers. >> >> The Haskellers hate state. >> >> This seemed strange at first because as a Smalltalker i love(d) state. State iswas my friend. >> >> 90% of my life as a Smalltalker is state wrangling. I am a state herder. >> >> The debugger is my staff I use to whack the state. And TestCase is my sheep dog. >> >> But to the Haskellers >> >> state is >> >> the evil trinity >> >> of >> >> satan the anti christ and the false prophet >> >> all rolled into one. >> >> State is the true dev incarnation of the total catastrophe of development Armageddon. >> >> Blood up to the bridles for hundreds of miles. Dogs and cats living together. Mass hysteria. >> >> They say. >> >> I'm not sure i quite get it yet but they keep preaching on this one point most of all. >> >> State is evil. >> >> You must keep all state in a Monad. As many methods/functions m as possible >> >> must be 100% dependent on the input parameters ONLY. >> >> No hidden instance variables affecting the return value of m are allowed. >> >> The only effect m can have is to return a value. >> >> If all this is true then m is pure. >> >> And pure is good. Pure is very good. And the wind says >> >> very. >> >> So i wonder if any of you fellow >> >> Smalltalkers >> >> have thought about this at all. > First, there are no good definitions of what is an object oriented language and what is a functional language. > Thus, languages like C++, C#, Java are being considered object oriented. But their object orientation is not the same like Smalltalkâs. > The same problem exists in the functional language world: Some consider LISP being functional, some deny that. > > Second, for some years I am constantly seeking for âthe bestâ language to solve my problems in. Alas I wasnât successful yet and donât expect > to be successful in the future. Every programming paradigm has its strengths and weaknesses when it comes to real world problems. > So in my eyes it is best to know the different programming paradigms and its representative languages in order to be able to choose the > best fitting language for your problem at hand. > > Third, there have been many attempts to create multi-paradigm languages (like C++, C#, Java, Scala, â¦). The idea behind is simple: combine > the best characteristics. In my eyes all of them failed because what always have been created is Frankensteinâs monster. When you combine > paradigms you will may get some advantages of all but sure you will get a lot of additional complexity. > > Fourth, it has been said many times before: What makes Smalltalk so nice is not only the language. Itâs the whole system: the language, duck typing, > the image (object world), the tools, the VM, the simplicity, the elegance, â¦ And last but not least the communities around. > > Regards > Andreas > > PS: If you are interested in functional programming and donât like static typing you should have a look at Clojure. It has some nice ideas about > how to deal with state concurrently. > > > >> Thanks >> >> Kjell E GodÃ¸ >> >> >> >> >> >> >> >> >> >> (((((((((( Maybe Smalltalk should be called Statewalk >> >> as in yak it up fuzz ball. )))))))))) >> >

July 6, 2015

Re: [Pharo-dev] Musings (Was: NAtiveBoost error)

by Kjell Godo

Thank you for the detailed reply Andreas Are there any Smalltalk packages implementing Category Theory based functional programming constructs for function composition like functors , applicatives , monads , arrows , etc ? Do people have opinions about whether or not these plus immutable data structures would be good for managing state in Smalltalk like they do it in Haskell etc? i know that monads are not built into Haskell but are implemented as addons via Haskell packages. My Haskell friend said all you need to do functional programming is first class functions which Smalltalk Block contexts almost are except they lack their own stack? if you wrap a Block in a Function Object do you then get the stack effect so you can essentially call the Block recursively? i have been wondering about taking a crack at implementing these in Smalltalk and i wonder if it would be theoretically possible to speed them up by inlining them via the Smalltalk compiler Thank you On Saturday, November 8, 2014, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: > > Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist(a)gmail.com > <javascript:_e(%7B%7D,'cvml','squeaklist(a)gmail.com');>>: > > This is off topic. > > I tried to post it as a top level thread but I have become unknown. > > Why do you expect that? Many people here are using Smalltalk for years. > Just because you have been silent for some time doesnât mean everybody > will forget about you :) > > > I don't know if you want this crap in here but I have decided not to wait > for the > > postmaster to get back to me on the subject of becoming known. Feel free. > > > > > > ( Original-SUBJECT: "( picoVerse-:( what about state , is state really > evil? ) )" ) > > > > > > > I am a Smalltalker. > > But in the past few months i have been running with the Haskellers. > > The Haskellers hate state. > > This seemed strange at first because as a Smalltalker i love(d) state. > State iswas my friend. > > 90% of my life as a Smalltalker is state wrangling. I am a state herder. > > The debugger is my staff I use to whack the state. And TestCase is my > sheep dog. > > But to the Haskellers > > state is > > the evil trinity > > of > > satan the anti christ and the false prophet > > all rolled into one. > > State is the true dev incarnation of the total catastrophe of development > Armageddon. > > Blood up to the bridles for hundreds of miles. Dogs and cats living > together. Mass hysteria. > > They say. > > I'm not sure i quite get it yet but they keep preaching on this one point > most of all. > > State is evil. > > You must keep all state in a Monad. As many methods/functions m as > possible > > must be 100% dependent on the input parameters ONLY. > > No hidden instance variables affecting the return value of m are allowed. > > The only effect m can have is to return a value. > > If all this is true then m is pure. > > And pure is good. Pure is very good. And the wind says > > very. > > So i wonder if any of you fellow > > Smalltalkers > > have thought about this at all. > > First, there are no good definitions of what is an object oriented > language and what is a functional language. > Thus, languages like C++, C#, Java are being considered object oriented. > But their object orientation is not the same like Smalltalkâs. > The same problem exists in the functional language world: Some consider > LISP being functional, some deny that. > > Second, for some years I am constantly seeking for âthe bestâ language to > solve my problems in. Alas I wasnât successful yet and donât expect > to be successful in the future. Every programming paradigm has its > strengths and weaknesses when it comes to real world problems. > So in my eyes it is best to know the different programming paradigms and > its representative languages in order to be able to choose the > best fitting language for your problem at hand. > > Third, there have been many attempts to create multi-paradigm languages > (like C++, C#, Java, Scala, â¦). The idea behind is simple: combine > the best characteristics. In my eyes all of them failed because what > always have been created is Frankensteinâs monster. When you combine > paradigms you will may get some advantages of all but sure you will get a > lot of additional complexity. > > Fourth, it has been said many times before: What makes Smalltalk so nice > is not only the language. Itâs the whole system: the language, duck typing, > the image (object world), the tools, the VM, the simplicity, the elegance, > â¦ And last but not least the communities around. > > Regards > Andreas > > PS: If you are interested in functional programming and donât like static > typing you should have a look at Clojure. It has some nice ideas about > how to deal with state concurrently. > > > > Thanks > > Kjell E GodÃ¸ > > > > > > > > > > (((((((((( Maybe Smalltalk should be called Statewalk > > as in yak it up fuzz ball. )))))))))) > > >

July 6, 2015