- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Help with PrStef with Fonts

by Nicolai Hess

Am 24.02.2016 5:29 nachm. schrieb "Nicolai Hess" <nicolaihess(a)gmail.com>: > > > Am 24.02.2016 5:26 nachm. schrieb "stepharo" <stepharo(a)free.fr>: > > > > > >>> > >>> may be > >>> > >>> showLesson: aLesson withTitle: aString > >>> self window setLabel: aString. > >>> self sourceTextModel setText: aLesson lesson. > >>> self isOpenInWindow ifFalse: [ self open ] > >>> > >>> > >>> but I do not know :( > >>> > >>> Stef > >>> > >> > >> Maybe both, > >> beForSmalltalkCode and beForSmalltalkScripting in > >> RubScrolledTextMorph should use > >> self textArea font: StandardFonts codeFont > >> > >> At the moment, only beForSmalltalkCode sets this font. > > > > > > Yes I did the same as you, I tried to add > > > > beForSmalltalkScripting > > self textArea beForSmalltalkScripting. > > > > self textArea font: StandardFonts codeFont > > > > But without success. I'm puzzled. > > Stef > > > > And you need to reset the tutorial, it reuses the existing lesson view. And maybe we should use beForSmalltalkScripting in the helpbrowser as well, because right now, you can not use "printIt"

Feb. 24, 2016

Re: [Pharo-dev] Help with PrStef with Fonts

by Nicolai Hess

Am 24.02.2016 5:26 nachm. schrieb "stepharo" <stepharo(a)free.fr>: > > >>> >>> may be >>> >>> showLesson: aLesson withTitle: aString >>> self window setLabel: aString. >>> self sourceTextModel setText: aLesson lesson. >>> self isOpenInWindow ifFalse: [ self open ] >>> >>> >>> but I do not know :( >>> >>> Stef >>> >> >> Maybe both, >> beForSmalltalkCode and beForSmalltalkScripting in >> RubScrolledTextMorph should use >> self textArea font: StandardFonts codeFont >> >> At the moment, only beForSmalltalkCode sets this font. > > > Yes I did the same as you, I tried to add > > beForSmalltalkScripting > self textArea beForSmalltalkScripting. > > self textArea font: StandardFonts codeFont > > But without success. I'm puzzled. > Stef > And you need to reset the tutorial, it reuses the existing lesson view.

Feb. 24, 2016

Re: [Pharo-dev] [Moose-dev] Call for action for Roassal

by stepharo

Anne did you publish the code you did with guillaume on reimplementing graphViz? Stef Le 24/2/16 10:28, Anne Etien a Ã©crit : > Hi Alexandre, > > In a wonderful world, I would like: > - a real graph layout (like in graphviz) that can take into account around hundred nodes and several hundred of edges and place the nodes in order to see something. Currently, I have to use the circle layout and it looks strange. > - the possibility to place hangout of the edges on nodes (as box) more flexible. Indeed, I am reverse engineering a database containing around 80 tables and lot of foreign keys and the result is not readable since the edge are orthogonal starting from the top or the bottom of the box corresponding to the column name. I would like a real entity-relation diagram. > > For the remainder, I use only Telescope since I have just to specify my data and not to script the visualization taking into account the order of the instructionsâ¦ So donât change the interface of the existing API in order we can continue to use Telescope on top on Roassal. > > If you want, I can show you the current stage of the visu (once again done in Telescope on top of Roassal) in order that you see on real data how uggly it is. > > Cheers, > Anne > >> Le 24 fÃ©vr. 2016 Ã 09:51, Alexandre Bergel <alexandre.bergel(a)me.com> a Ã©crit : >> >> Dear community, >> >> As you may have seen, Roassal has entered a stabilization phase. The book AgileVisualization.com will soon be released. After its release, Roassal will go over a new development phase. In order to prepare it, I am asking this question: >> >> What are the 3 aspects you would like to see improved in Roassal? >> >> You can answer publicly or by sending private messages. >> >> Kind regards, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > >

Feb. 24, 2016

Re: [Pharo-dev] Help with PrStef with Fonts

by stepharo

> > may be > > showLesson: aLesson withTitle: aString > self window setLabel: aString. > self sourceTextModel setText: aLesson lesson. > self isOpenInWindow ifFalse: [ self open ] > > > but I do not know :( > > Stef > > > Maybe both, > beForSmalltalkCode and beForSmalltalkScripting in > RubScrolledTextMorph should use > self textArea font: StandardFonts codeFont > > At the moment, only beForSmalltalkCode sets this font. Yes I did the same as you, I tried to add beForSmalltalkScripting self textArea beForSmalltalkScripting. self textArea font: StandardFonts codeFont But without success. I'm puzzled. Stef

Feb. 24, 2016

Re: [Pharo-dev] [Bloc] MDLColor and new gradient

by stepharo

I do not know. May be. Le 23/2/16 10:30, Denis Kudriashov a Ã©crit : > Hi > > 2016-02-23 9:13 GMT+01:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > May be we should have some Palette > > And we could have (brainstorming) > > (ColorBuilder from: MDLPalette) > -> aColorBuilder > aColorBuilder red > -> .... > > > What the difference between red colors from different palettes? And > why it is not just "MDLPalette red"?

Feb. 24, 2016

Re: [Pharo-dev] [Bloc] MDLColor and new gradient

by stepharo

tx for the pointer Le 24/2/16 10:34, Glenn CavarlÃ© a Ã©crit : > Hi, > In my memories, a first implementation of material colors was also made by > Alex in Brick packages. > This can be a inspiration source, too. > > > > ----- > Glenn CavarlÃ© > -- > View this message in context: http://forum.world.st/Bloc-MDLColor-and-new-gradient-tp4879795p4880198.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Feb. 24, 2016

Process>>restart

by Ben Coman

Just sharing a passing thought so I don't forget it before I have time to think more deeply on it. Several parts of Pharo (like SHTextStyler) are designed to have a background process running, and when new input arrives that process is killed so another can be immediately started - and sometimes we seem to end up with large amounts of zombie processes. As I poke around Process>>terminate, I wonder if a different approach would be to have a Process>>restart. I see there is Context>>restart. The starting the background process might look like... stylingProcess := [ [ "do stuff with nextData". self suspend ] repeat ] forkAt: 30. and the code in the main morphic priority 40 thread might look like... sylingProcess suspend. nextData := 'blah'. sylingProcess restart. anyway, back to the grind for me, cheers -ben

Feb. 24, 2016

[pharo-project/pharo-core]

by GitHub

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

Feb. 24, 2016

[pharo-project/pharo-core] 14f6ba: 50608

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 14f6bab879eb513900b9dd6b01726ffd66291c80 https://github.com/pharo-project/pharo-core/commit/14f6bab879eb513900b9dd6b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-24 (Wed, 24 Feb 2016) Changed paths: M FreeType.package/FT2Face.class/instance/initialize-release/newFaceFromExternalMemory_index_.st M FreeType.package/FT2Face.class/instance/initialize-release/newFaceFromFile_index_.st A FreeType.package/FT2Face.class/instance/private-primitives/primNewFaceFromExternalMemory_size_index_.st M FreeType.package/FT2Face.class/instance/private/loadFields.st R FreeType.package/FT2Handle.class/instance/printing/isValid.st A FreeType.package/FT2Handle.class/instance/testing/isValid.st M FreeType.package/FreeTypeFace.class/definition.st R FreeType.package/FreeTypeFace.class/instance/initialize-release/beNull.st R FreeType.package/FreeTypeFace.class/instance/testing/isValid.st M FreeType.package/FreeTypeFace.class/instance/validation/create.st R FreeType.package/FreeTypeFace.class/instance/validation/newFaceFromExternalMemory_index_.st R FreeType.package/FreeTypeFace.class/instance/validation/newFaceFromFile_index_.st R FreeType.package/FreeTypeFace.class/instance/validation/primNewFaceFromExternalMemory_size_index_.st M FreeType.package/FreeTypeFace.class/instance/validation/validate.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50607.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50608.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50607.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50608.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50608 17392 FreeType numCharMaps nil causes Array>>basicNew: to fail https://pharo.fogbugz.com/f/cases/17392 http://files.pharo.org/image/50/50608.zip

Feb. 24, 2016

Re: [Pharo-dev] [Moose-dev] Call for action for Roassal

by Peter UhnÃ¡k

On Wed, Feb 24, 2016 at 3:11 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Make it working with all graphviz tools and it will be wonderful already. > BTW, there is already a tool generating graphviz things as this is what > was used to document seaside dependencies. > Yes, this is what I used to generate the GraphViz .dot file. http://smalltalkhub.com/#!/~hernan/GraphViz But I had to parse the results myself from SVG, because the default one had some precision issues (this was most likely GraphViz problems). Peter

Feb. 24, 2016