August 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Dark Mode

by Peter UhnÃ¡k

> Too bad Pharo isn't themable. If you don't know whether it is themable, you can just ask instead of issuing statements. ;) I've also seen Sublimish theme (don't know where the repo is), Dark Metal Theme ( https://github.com/estebanlm/themes ), Kilon has blue-ish theme (I don't think he published it anywhere), and there was also ubuntu theme (not sure if it still works, https://pharoweekly.wordpress.com/2015/07/04/ubuntu-theme-for-pharo/) But white & dark are supported. (I switch between them regularly, especially on projector.) Of course you can create your own theme. Peter On Sun, Aug 27, 2017 at 11:55 AM, Tim Mackinnon <tim(a)testit.works> wrote: > It's also a single click in the Welcome screen - which is maybe too > obvious ;) > > Tim > > Sent from my iPhone > > > On 27 Aug 2017, at 03:17, horrido <horrido.hobbies(a)gmail.com> wrote: > > > > Oh, cool! I didn't realize that. (I've never had a need to look at > Settings.) > > > > Thanks. > > > > > > > > -- > > View this message in context: http://forum.world.st/Dark- > Mode-tp4964409p4964436.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > >

Aug. 27, 2017

Re: [Pharo-users] Dark Mode

by Tim Mackinnon

It's also a single click in the Welcome screen - which is maybe too obvious ;) Tim Sent from my iPhone > On 27 Aug 2017, at 03:17, horrido <horrido.hobbies(a)gmail.com> wrote: > > Oh, cool! I didn't realize that. (I've never had a need to look at Settings.) > > Thanks. > > > > -- > View this message in context: http://forum.world.st/Dark-Mode-tp4964409p4964436.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Aug. 27, 2017

Re: [Pharo-users] Dark Mode

by Alistair Grant

On Sat, Aug 26, 2017 at 03:40:04PM -0700, horrido wrote: > I found this interesting article > <https://hackernoon.com/apple-and-others-need-a-dark-mode-for-people-like-mo…> > . I wanted to express my opinion... > > Dark mode looks cool and all, but it does have a downside. I was very happy > with the normal Pharo 5.0 look, but when Pharo 6.0 came out with its dark > theme, I was rather put off by it. For me, at least, the dark theme makes it > harder to read the text. Too bad Pharo isn't themable. I completely agree - dark mode is great for content that you want to look cool, but no one consumes. :-) You can also automate switching to the light theme with a startup.st: StartupPreferencesLoader default executeAtomicItems: { StartupAction name: 'Set light theme' code: [ Pharo3Theme beCurrent ] runOnce: true. } Disclaimer: my startup.st is different, I haven't tested this, but hopefully you can figure it out from here. Cheers, Alistair

Aug. 27, 2017

Re: [Pharo-users] The Spec UI Framework. first translation to korean finish.

by Serge Stinckwich

Hi Peter, this is really a nice work ! You should consider converting your document to Pillar and host it on SquareBrackets org git repository, because it will be easier for others to contribute. Thank you for your support to the Pharo community Le 26 aoÃ»t 2017 Ã 22:52 +0200, peter yoo <onionmixer(a)gmail.com>, a Ã©crit : > hello. for pharo guys. Long time no see. > > It is not easy for Korean people to study pharo. Very few people use smalltalk. Of course, it is hard to find Korean language resources. > > Recently I went to find the spec framework to study Pharo. Of course I looked at morphic designer in squeak, but I believe in pharo team. > > I have translated it with the help of google for those who want to study. I refer to the pillar source of git. I wanted to work with pdf, but I know xetex, but I do not know about pillar and luatex. So I put it on the wiki. > > Thank you for always making good pharo. > > > http://trans.onionmixer.net/mediawiki/index.php?title=TheSpecUIframework > > -- > http://lookandwalk.com Â http://looknw.com | http://onionmixer.net > peter yoo(Jonghwa Yoo). ROK

Aug. 27, 2017

Re: [Pharo-users] [ann] moldable editor - with expandable elements

by Thierry Goubier

Hi Doru, 2017-08-27 9:24 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Aug 27, 2017, at 12:06 AM, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Hi Tim, > > > > 2017-08-26 23:27 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > > I think you pose some interesting design challenges - but it's worthy of > experimentation. > > > > I share Denis' enthusiasm to build something better - but it's true it's > not an easy problem space. > > > > I'm a big fan of GTInspector, but sometimes I slide across and lose my > context (not always, and not for all types of problems). > > > > I think you may be on the key issue, the loss of context when navigating > through the code. In the 90's, that was called the 'lost in hyperspace' > problem linked with hypertexts and hypermedia. > > > > I'm not sure it was ever resolved (I stopped following that research > community during my PhD), apart from considering that google solved it for > the web. At least, this would be the choice made by Newspeak: consider that > the code is like the web, and build a system web browser. > > > > > > For unique extractions - inlining is a no brainer (it's just like code > folding in many editors). For non-unique, maybe something in the gutter > might let you easily flip... I don't know, but I'm not convinced our > current way is always optimal. > > > > Agreed. I have changed the way I code to reduce the context needed to > understand it. > > > > > > Still, the whole moldable idea is to make it easy to experiment - and > that's the cool bit. That's where we thrive. > > > > Smalltalk has allways been open to that sort of experiment. The moldable > bit may make it easier, or at least not more complex than it was when > Smalltalk systems were a lot smaller. Now, is that moldable implementation > really that free, or has it sacrificed certain freedoms to make moldable > things easier? > > Please let me intervene briefly :). > > Smalltalk was always indeed open. However, we noticed that regardless of > the application domain, tools essentially looked the same for these > systems. All Smalltalkers I asked extended Object at least once, but before > the GTInspector, most of them never extended the inspector. Our language > was extremely dynamic, but our tools less so. That is a conceptual problem > that we address with what we call moldability. > Hum. From 1992 to now, I would make the same statement in the Smalltalk world, mostly talking a certain conservatism first (look at how much the system browser has evolved over the years), but also some questions about efficiency of alternative forms. For example, the code view of the GTInspector remain for me as one of the clumsiest, worse view I've ever seen in the Smalltalk world for editing code. > > The goal of moldability is to make it inexpensive to customize. To this > end, we approach the IDE as a language and the moldability is captured in > the operators that language provides. Of course, there are limitations to > what can be doable inexpensively. However, it turns out that if you do > manage to bring the cost to a radical low cost, you get much more > extensions and experimentations going on. > I'm a bit missing where the moldability of the IDE went, in that context. You seem to stear very clear from anything related to the system browser... > > All infrastructures make certain things easier and others less so. The > value of all this does depend on what are the operators and how deep in the > infrastructure they are placed. For example, the moldable editor shows > these expandable elements as part of syntax highlighting. Syntax > highlighting existed since a long time, so making it also able to show > other things is quite powerful and requires nothing hardcoded. In fact, I > do not know of any other editor that can do that while still having the > performance we get. > ? Especially that last statement. Adding non text elements in an editor has allways been a fairly easy endeavour in ST, as long as I could remember (1993?). Performance on long texts is orthogonal to Bloc, right? It is present in all editors that do formatting on long documents since the first WYSIWIG editors appeared in the 80's. And, so far, the examples you're showing means that editor isn't as capable as Doc (in 1989/1990?) was. I a bit worried about that syntax highlighting approach. It seems to me very tied to a text + attributes representation instead of an object representation, and I find that API in Pharo horribly clumsy and ineffective, for the apparent benefit of slightly reducing object storage size with a kind of RLE compression. > > But, even more important than tool features is the behavior of people. For > example, when we first introduced the inspector, all talk was about details > (e.g., how it is clumsy to navigate laterally). 2 years later, at this > yearâs PharoDays most talks used the GTInspector in one way or another to > exemplify the presentation. This is a significant impact and this is what > we are after. > Yes. This is clearly where the Pharo platform is showing some innovation in the ability to shape better object representations. At the same time, GUI-wise, there is very little innovation in the GUI language used; GT provides a very limited language, for the sake of efficiency and ease (*). But maybe it can't be done in another way, if you want people to really build their extensions. > > At feenk, we donât say that we build tools. We see ourselves as designing > experiences. > Which is a worthwhile goal. Regards, Thierry (*) Such layers represent a so huge investment anyway, so it may be unavoidable. > > Cheers, > Doru > > > > > Regards, > > > > Thierry > > > > > > Tim > > > > Sent from my iPhone > > > > On 26 Aug 2017, at 18:38, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > >> > >> > >> 2017-08-26 15:44 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> No Thierry, Newspeak do not allow it. And it not looks similar to what > I want. > >> > >> Hum, you would still get the same overall approach: editor inside > editor (or view inside view). Now, you can say it is not the same, up to > you. > >> > >> For me, it has the same effect: the editor isn't in a single place > anymore. You may consider it doesn't matter; IMHO it does matter (and it > makes for me the Newspeak editor slightly less efficient; the same that the > Smalltalk system browser seemed more effective than the Self in-place > method edit, for having used both). > >> > >> > >> Now command+click on selector opens implementors window. In past it > moved browser to single implementor. It was nice and it is how other IDEs > are working. > >> > >> You miss the past behaviour? Why not adding it again? > >> > >> But as Tim notice it always loses context. And it is quite difficult to > browse long call chain which include many small methods. > >> > >> I'm not sure it would solve that one. > >> > >> Either it is a long call chain with a fan-out of one, in which case the > developper is creating many useless single line methods because it is "the > right way"(tm), or it has a fan-out greater than one (your typical > polymorphic code) and then each time you open, you have half a dozen > implementors. > >> > >> For that, you already have the flow browser. > >> > >> So with new editor command+click will be able expand implementor just > in place. I think it will be big improvement for IDE. > >> > >> As I said, with Calypso and Nautilus handling badly long methods, then > a method inside a method just makes the top level method longer... I'd like > to see you do that on Metacello or SmaCC code, where important methods > easily go over 50 lines before you expand anything. > >> > >> I'd say there that the GTInspector approach would work better -> expand > on the right, with the ability to keep two side by side, and overlaid with > lines clearly showing what has been expanded (for that "context" thing). > >> > >> Regards, > >> > >> Thierry > >> > >> > >> 2017-08-26 14:59 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> > >> > >> 2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> > >> 2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > >> Denis - that's a very cool idea if I've understood you - expand in the > source code of the current method, literally inline? So you could scroll up > and down to view the context as you expand it out? > >> > >> Yes, exactly. > >> > >> Then that would look a bit like the NewSpeak code browser, if you would > like to try the concept. > >> > >> There are disadvantages to that paradigm. One of those is that the > system browser in Pharo is ill-suited to long methods. > >> > >> Thierry > >> > >> > >> One of the complaints around refactoring is that you lose context of > surrounding code - intelligent in place expansion would be the best of both > worlds... > >> > >> Tim > >> > >> Sent from my iPhone > >> > >> On 26 Aug 2017, at 11:40, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> > >>> This is really cool. It opens so many possibilities. > >>> > >>> I imaging method editor where message sends can be expanded to > implementors just in place. > >>> > >>> 2017-08-26 1:03 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >>> Hi, > >>> > >>> We are really pleased to announce another major advancement in the > development of the moldable editor, and most of it was enabled because of > one new feature: expandable elements. We think this will impact > significantly our day to day interactions. > >>> > >>> To exemplify what we mean, we will make use of two more alpha projects > that we did not announce yet: GT Documenter (a set of documentation tools > based on Pillar and GT Examples) and GT Mondrian (the graph visualization > engine), both of which are being implemented in Bloc. > >>> > >>> Please take a look at the following pictures showing the documentation > Pillar file that ships together with GT Mondrian. What stands out are the > two embedded pictures. These are actually not pictures, but visualizations > rendered live during the viewing of the document out of a referenced GT > Example. > >>> > >>> > >>> > >>> Now, GT Examples are likely also new for most people. We introduced > them a couple of years ago based on the original idea of Markus Gaelli. > These are a kind of tests that return an object and that can be built out > of other examples. The nice thing is that they are always executable and > testable. So, of course, if you see the resulting object, you can also see > the code that created it, and if you see the code, you can even execute it > live, right in place (notice the preview of the second snippet). > >>> > >>> <pillar-mondrian-expanded-preview.png> > >>> > >>> Perhaps the most controversial part of GT Examples is that they offer > a mechanism to define static dependencies via pragmas. Please, letâs leave > this debate to another occasion, but please also notice that tools can use > that static information to unfold the code of the referenced method (notice > the nested code editors). > >>> > >>> A side note: if you look closer at the list with three items at the > top of the Tutorial section, you will notice numbering next to #. That is > actually syntax highlighting and so is the mechanism that embeds the > expandable elements. Itâs really cool. > >>> > >>> Taking step back, when we introduced the editor a few weeks ago, we > called it moldable because we said we can make it take different shapes > easily. GT Documenter with everything you see in the above screenshots has > currently ~500 lines of code, and all this while still having an editor > that is highly scalable. > >>> > >>> We think that Bloc and Brick will change dramatically face of Pharo > and now we can start to get a glimpse of what is possible. For example, the > use case presented above is more than a technical tool, and we think this > will change both the way we write documentation and the way we consume it. > >>> > >>> All these will be presented at ESUG both during presentations and at > the Innovation Awards competition. In the meantime, those that want to play > with it can execute the following in both Pharo 6.1 and Pharo 7.0: > >>> > >>> Iceberg enableMetacelloIntegration: true. > >>> Metacello new > >>> baseline: 'GToolkit'; > >>> repository: 'github://feenkcom/gtoolkit/src'; > >>> load. > >>> > >>> And then inspect: > >>> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' > asFileReference > >>> > >>> Cheers, > >>> The feenk team > >>> > >>> -- > >>> www.tudorgirba.com > >>> www.feenk.com > >>> > >>> "Innovation comes in the least expected form. > >>> That is, if it is expected, it already happened." > >>> > >>> > >> > >> > >> > >> > > > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving efficiency grows with the abstractness level of problem > understanding." > > > > > >

Aug. 27, 2017

Re: [Pharo-users] [ann] moldable editor - with expandable elements

by Tudor Girba

Hi, > On Aug 27, 2017, at 12:06 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Tim, > > 2017-08-26 23:27 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > I think you pose some interesting design challenges - but it's worthy of experimentation. > > I share Denis' enthusiasm to build something better - but it's true it's not an easy problem space. > > I'm a big fan of GTInspector, but sometimes I slide across and lose my context (not always, and not for all types of problems). > > I think you may be on the key issue, the loss of context when navigating through the code. In the 90's, that was called the 'lost in hyperspace' problem linked with hypertexts and hypermedia. > > I'm not sure it was ever resolved (I stopped following that research community during my PhD), apart from considering that google solved it for the web. At least, this would be the choice made by Newspeak: consider that the code is like the web, and build a system web browser. > > > For unique extractions - inlining is a no brainer (it's just like code folding in many editors). For non-unique, maybe something in the gutter might let you easily flip... I don't know, but I'm not convinced our current way is always optimal. > > Agreed. I have changed the way I code to reduce the context needed to understand it. > > > Still, the whole moldable idea is to make it easy to experiment - and that's the cool bit. That's where we thrive. > > Smalltalk has allways been open to that sort of experiment. The moldable bit may make it easier, or at least not more complex than it was when Smalltalk systems were a lot smaller. Now, is that moldable implementation really that free, or has it sacrificed certain freedoms to make moldable things easier? Please let me intervene briefly :). Smalltalk was always indeed open. However, we noticed that regardless of the application domain, tools essentially looked the same for these systems. All Smalltalkers I asked extended Object at least once, but before the GTInspector, most of them never extended the inspector. Our language was extremely dynamic, but our tools less so. That is a conceptual problem that we address with what we call moldability. The goal of moldability is to make it inexpensive to customize. To this end, we approach the IDE as a language and the moldability is captured in the operators that language provides. Of course, there are limitations to what can be doable inexpensively. However, it turns out that if you do manage to bring the cost to a radical low cost, you get much more extensions and experimentations going on. All infrastructures make certain things easier and others less so. The value of all this does depend on what are the operators and how deep in the infrastructure they are placed. For example, the moldable editor shows these expandable elements as part of syntax highlighting. Syntax highlighting existed since a long time, so making it also able to show other things is quite powerful and requires nothing hardcoded. In fact, I do not know of any other editor that can do that while still having the performance we get. But, even more important than tool features is the behavior of people. For example, when we first introduced the inspector, all talk was about details (e.g., how it is clumsy to navigate laterally). 2 years later, at this yearâs PharoDays most talks used the GTInspector in one way or another to exemplify the presentation. This is a significant impact and this is what we are after. At feenk, we donât say that we build tools. We see ourselves as designing experiences. Cheers, Doru > Regards, > > Thierry > > > Tim > > Sent from my iPhone > > On 26 Aug 2017, at 18:38, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > >> >> >> 2017-08-26 15:44 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> No Thierry, Newspeak do not allow it. And it not looks similar to what I want. >> >> Hum, you would still get the same overall approach: editor inside editor (or view inside view). Now, you can say it is not the same, up to you. >> >> For me, it has the same effect: the editor isn't in a single place anymore. You may consider it doesn't matter; IMHO it does matter (and it makes for me the Newspeak editor slightly less efficient; the same that the Smalltalk system browser seemed more effective than the Self in-place method edit, for having used both). >> >> >> Now command+click on selector opens implementors window. In past it moved browser to single implementor. It was nice and it is how other IDEs are working. >> >> You miss the past behaviour? Why not adding it again? >> >> But as Tim notice it always loses context. And it is quite difficult to browse long call chain which include many small methods. >> >> I'm not sure it would solve that one. >> >> Either it is a long call chain with a fan-out of one, in which case the developper is creating many useless single line methods because it is "the right way"(tm), or it has a fan-out greater than one (your typical polymorphic code) and then each time you open, you have half a dozen implementors. >> >> For that, you already have the flow browser. >> >> So with new editor command+click will be able expand implementor just in place. I think it will be big improvement for IDE. >> >> As I said, with Calypso and Nautilus handling badly long methods, then a method inside a method just makes the top level method longer... I'd like to see you do that on Metacello or SmaCC code, where important methods easily go over 50 lines before you expand anything. >> >> I'd say there that the GTInspector approach would work better -> expand on the right, with the ability to keep two side by side, and overlaid with lines clearly showing what has been expanded (for that "context" thing). >> >> Regards, >> >> Thierry >> >> >> 2017-08-26 14:59 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >> >> 2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> 2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >> Denis - that's a very cool idea if I've understood you - expand in the source code of the current method, literally inline? So you could scroll up and down to view the context as you expand it out? >> >> Yes, exactly. >> >> Then that would look a bit like the NewSpeak code browser, if you would like to try the concept. >> >> There are disadvantages to that paradigm. One of those is that the system browser in Pharo is ill-suited to long methods. >> >> Thierry >> >> >> One of the complaints around refactoring is that you lose context of surrounding code - intelligent in place expansion would be the best of both worlds... >> >> Tim >> >> Sent from my iPhone >> >> On 26 Aug 2017, at 11:40, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >>> This is really cool. It opens so many possibilities. >>> >>> I imaging method editor where message sends can be expanded to implementors just in place. >>> >>> 2017-08-26 1:03 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> Hi, >>> >>> We are really pleased to announce another major advancement in the development of the moldable editor, and most of it was enabled because of one new feature: expandable elements. We think this will impact significantly our day to day interactions. >>> >>> To exemplify what we mean, we will make use of two more alpha projects that we did not announce yet: GT Documenter (a set of documentation tools based on Pillar and GT Examples) and GT Mondrian (the graph visualization engine), both of which are being implemented in Bloc. >>> >>> Please take a look at the following pictures showing the documentation Pillar file that ships together with GT Mondrian. What stands out are the two embedded pictures. These are actually not pictures, but visualizations rendered live during the viewing of the document out of a referenced GT Example. >>> >>> >>> >>> Now, GT Examples are likely also new for most people. We introduced them a couple of years ago based on the original idea of Markus Gaelli. These are a kind of tests that return an object and that can be built out of other examples. The nice thing is that they are always executable and testable. So, of course, if you see the resulting object, you can also see the code that created it, and if you see the code, you can even execute it live, right in place (notice the preview of the second snippet). >>> >>> <pillar-mondrian-expanded-preview.png> >>> >>> Perhaps the most controversial part of GT Examples is that they offer a mechanism to define static dependencies via pragmas. Please, letâs leave this debate to another occasion, but please also notice that tools can use that static information to unfold the code of the referenced method (notice the nested code editors). >>> >>> A side note: if you look closer at the list with three items at the top of the Tutorial section, you will notice numbering next to #. That is actually syntax highlighting and so is the mechanism that embeds the expandable elements. Itâs really cool. >>> >>> Taking step back, when we introduced the editor a few weeks ago, we called it moldable because we said we can make it take different shapes easily. GT Documenter with everything you see in the above screenshots has currently ~500 lines of code, and all this while still having an editor that is highly scalable. >>> >>> We think that Bloc and Brick will change dramatically face of Pharo and now we can start to get a glimpse of what is possible. For example, the use case presented above is more than a technical tool, and we think this will change both the way we write documentation and the way we consume it. >>> >>> All these will be presented at ESUG both during presentations and at the Innovation Awards competition. In the meantime, those that want to play with it can execute the following in both Pharo 6.1 and Pharo 7.0: >>> >>> Iceberg enableMetacelloIntegration: true. >>> Metacello new >>> baseline: 'GToolkit'; >>> repository: 'github://feenkcom/gtoolkit/src'; >>> load. >>> >>> And then inspect: >>> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference >>> >>> Cheers, >>> The feenk team >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Innovation comes in the least expected form. >>> That is, if it is expected, it already happened." >>> >>> >> >> >> >> > -- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."

Aug. 27, 2017

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

by Ben Coman

Within WorldState>>doOneCycle, try writing to a file every second, and at the command line use... tail -f ... to see if it keeps writing when the screen is frozen. And also try writing to a file in a forked process. cheers -ben On Sun, Aug 27, 2017 at 1:58 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > But it is a freeze or a screen refresh problem? > Can you try to command . heavily on your frozen image? > > On Sat, Aug 26, 2017 at 2:48 PM, Ben Coman <btc(a)openinworld.com> wrote: > > Hi Ted, > > > > You might consider building a debug VM. There is a random chance it > > provides useful insight. > > At its simplest all you need to do is... > > $ git clone https://github.com/OpenSmalltalk/opensmalltalk-vm.git > > $ cd opensmalltalk-vm/build.macos32x86/pharo.cog.spur > > $ ./mvm -A > > > > taken from... > > https://github.com/OpenSmalltalk/opensmalltalk- > vm/blob/Cog/build.macos32x86/HowToBuild > > > > First confirm the problem still exists in each of three generated VMs > > started normally, > > then later try using lldb to trace what methods are executed. > > (though I'm not familiar with lldb - you'll need to google some > tutorials) > > > > cheers -ben > > > > On Fri, Aug 25, 2017 at 9:55 PM, TedVanGaalen <tedvga(a)gmail.com> wrote: > >> > >> Hi Ben, > >> Did the following > >> - restoring Pharo.app/Contents/MacOS/Plugins/libFT2Plugin.dylib (by > >> renaming its extension back to .dylib) > >> - started Pharo > >> -setting use Free type ON > >> -setting Update fonts at start ON > >> > >> it then immediately starts loading fonts, (which I thought might be a > >> good idea > >> because perhaps fonts were not completely loaded in the image, > >> but that didnât make any difference) > >> > >> -saved and quit > >> -fired up Pharo again. > >> > >> didnât help. Same problems occur > >> > >> then: (as you have asked) > >> > >> - started Pharo again > >> -setting use Free type OFF > >> -setting Update fonts at start OFF > >> -saved and quit > >> -fired up Pharo again. > >> > >> didnât help either > >> > >> I have no idea what the cause might be, > >> but if you have other suggestions to test > >> I be glad to help. (if not a thousand attempts :o) > >> > >> in the mean time I use 5 until a next release comes out 7 ? that works > ok. > >> > >> kind regards > >> TedvG > >> > >> > >> > >> > >> On 25. Aug 2017, at 06:07, Ben Coman [via Smalltalk] <[hidden email]> > >> wrote: > >> > >> What happens if you untick "Use FreeType" in System > Settings? > >> > >> cheers -ben > >> > >> > >> On Thu, Aug 24, 2017 at 10:06 PM, TedVanGaalen <<a > >> href="x-msg://1/user/SendEmail.jtp?type=node&node=4963983&i=0" > >> target="_top" rel="nofollow" link="external" class="">[hidden email]> > wrote: > >>> > >>> yes, after full screen -> normal window -> minimise -> reshow it did. > >>> (not in any particular order, tried al those before as well) > >>> > >>> TedvG > >>> > >>> > >>> On 24. Aug 2017, at 15:46, EstebanLM [via Smalltalk] <[hidden email]> > >>> wrote: > >>> > >>> and image still freezing? > >>> > >>> Esteban > >>> > >>> On 24 Aug 2017, at 15:28, TedVanGaalen <<a href="<a > >>> href="x-msg://3/user/" > >>> class="">x-msg://3/user/SendEmail.jtp?type=node& > node=4963878&i=0" > >>> target="_top" rel="nofollow" link="external" class="">[hidden email]> > wrote: > >>> > >>> Hi Esteban, > >>> unfortunately that doesnât make any difference. > >>> What I did: > >>> extension temporarily renamed to â¦..wasAdylib > >>> Started Pharo app by clikcing on it (gets the downloaded maiden image) > >>> then: > >>> âFT2Error:Freetype2 primitive failed [error -1][canât get error > string]â > >>> > >>> > >> > >> > >> > >> ________________________________ > >> If you reply to this email, your message will be added to the discussion > >> below: > >> > >> http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on- > MacMini-tp4957969p4963983.html > >> To unsubscribe from Pharo 6.0 and 6.1 64 bit freeze on MacMini, click > >> here. > >> NAML > >> > >> > >> > >> ________________________________ > >> View this message in context: Re: Pharo 6.0 and 6.1 64 bit freeze on > >> MacMini > >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > >

Aug. 27, 2017

Re: [Pharo-users] Dark Mode

by Cyril Ferlicot D.

Le 27/08/2017 Ã 02:52, Damien Pollet a Ã©crit : > Sure it isâ¦ AFAIK the light theme is still available in the settings > There is also the possibility to do it through the welcome window. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Aug. 27, 2017

Re: [Pharo-users] Dark Mode

by horrido

Oh, cool! I didn't realize that. (I've never had a need to look at Settings.) Thanks. -- View this message in context: http://forum.world.st/Dark-Mode-tp4964409p4964436.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 27, 2017

Re: [Pharo-users] Dark Mode

by Damien Pollet

Sure it isâ¦ AFAIK the light theme is still available in the settings On 27 August 2017 at 00:40, horrido <horrido.hobbies(a)gmail.com> wrote: > I found this interesting article > <https://hackernoon.com/apple-and-others-need-a-dark-mode- > for-people-like-molly-watt-ae9fdc38479f> > . I wanted to express my opinion... > > Dark mode looks cool and all, but it does have a downside. I was very happy > with the normal Pharo 5.0 look, but when Pharo 6.0 came out with its dark > theme, I was rather put off by it. For me, at least, the dark theme makes > it > harder to read the text. Too bad Pharo isn't themable. > > > > -- > View this message in context: http://forum.world.st/Dark- > Mode-tp4964409.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Aug. 27, 2017