February 2016 - Pharo-dev - lists.pharo.org

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

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

by phil＠highoctane.be

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. Here us thread: http://forum.world.st/GraphViz-renggli-repo-down-td4722561.html Seems that Roassal 1 had such a thing already. Phil On Wed, Feb 24, 2016 at 10:44 AM, Anne Etien <anne.etien(a)univ-lille1.fr> wrote: > > Le 24 fÃ©vr. 2016 Ã 10:35, Peter UhnÃ¡k <i.uhnak(a)gmail.com> a Ã©crit : > > > > On Wed, Feb 24, 2016 at 10:28 AM, Anne Etien <anne.etien(a)univ-lille1.fr> > wrote: > >> 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. >> > > Unfortunately making real graph layouts is really hard issueâ¦ I've wrote > my bachelor thesis about this and didn't get very far; it's bit of a > nightmare if you don't have good foundations. :â( > > > I know. I tried but my mathematical background and my time were not > enough. I got the research paper explaining the algorithm of Graphviz but > even with that, it was very complex. However, since some tools (as > graphviz) do it, we should have it. > > Anne > > > In any case, I wrote a simpler layout delegator in Roassal that delegates > the layouting to graphviz and it works reasonably well, so I could probably > add it to Roassal (you however need graphviz installed and it would add > another dependency to Roassal, which I'm not so keen on). > > Maybe also OGDF (http://ogdf.net/doku.php) could be used if you are ok > with GPLâ¦ they have their own graph format so there could be some > interaction. > > Peter > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > >

Feb. 24, 2016

reviews needed: Cleanup of RubParagraphDecorator drawing

by Marcus Denker

Hi, It would be nice if we could review and integrate this: Cleanup of RubParagraphDecorator drawing https://pharo.fogbugz.com/f/cases/17062

Feb. 24, 2016

Re: [Pharo-dev] Git written entirely in Smalltalk?

by Damien Cassou

Ben Coman <btc(a)openinworld.com> writes: > The other say I was contemplating having a git implementation written > entirely in Pharo, and today I bumped into something from your history > (~2011?) [1] indicating this might have been attempted. I'm curious > why this was abandoned in favour of libgit bindings. Max did most of the work IIRC. Then Camillo and I tried to help. But this is difficult to do because the git protocol is complex and we had not much time to dive into it. We also didn't find good documentation. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Feb. 24, 2016

Re: [Pharo-dev] Git written entirely in Smalltalk?

by Max Leske

:) It wasnât a complete implementation but entirely written in Pharo, yes. The reason I decided to go for bindings is that Git is quite big. There are many things to implement and thereâs a lot of mystery when it comes to implementation details. Using bindings reduces the cost of maintenance a lot, since the burden of updating and fixing stuff is no longer on me. Additionally, performance was never really good with my solution, partly due to the VM of course (FFI wasnât really an option for me back then, so all the calculations were done in the image). And finally, Git has a rather unconventional way of handling memory: allocate until it breaks. Since weâre quite constrained memory wise in Pharo, I would run into out of memory situations pretty quickly. Handing the memory management off to the library makes things a lot easier. BTW, I based my project on the work of Tony Garnock-Jones (from NZ) who started work on a Git implementation for Squeak (but then gave up the project). Cheers, Max > On 24 Feb 2016, at 12:30, Ben Coman <btc(a)openinworld.com> wrote: > > Max, > > The other say I was contemplating having a git implementation written > entirely in Pharo, and today I bumped into something from your history > (~2011?) [1] indicating this might have been attempted. I'm curious > why this was abandoned in favour of libgit bindings. > > [1] http://scg.unibe.ch/wiki/students/maxleske > > cheers -ben >

Feb. 24, 2016

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

by Alexandre Bergel

>> Dear community, >> What are the 3 aspects you would like to see improved in Roassal? > > My favorite improvement would not really be a Roassal feature > but would save me a lot of time: > I would like the configuration versions to stop depending on numbered versions of outside dependencies (Glamour, Neo-JSON-Core) Hi! I do not get this. Relying on the baseline is not enough? Roassal is very simply packaged. Only 4 packages: Roassal, Trachel, Roassal2Spec, Roassal2GT. It is very unlikely that this list of package will grow (not until we have a Git integration at least). You can make your configuration directly point to these packages no? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 24, 2016

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

by Nicolai Hess

2016-02-24 12:18 GMT+01:00 stepharo <stepharo(a)free.fr>: > Hi > > I'm trying to understand why PrStef does not use the fonts I defined for > shooting the videos > > StandardFonts codeFont: > (LogicalFont familyName: 'Source Code Pro' pointSize: 15). > StandardFonts defaultFont: > (LogicalFont familyName: 'Source Code Sans' pointSize: 13). > StandardFonts listFont: > (LogicalFont familyName: 'Source Code Sans' pointSize: 18). > StandardFonts menuFont: > (LogicalFont familyName: 'Source Code Sans' pointSize: 18). > StandardFonts buttonFont: > (LogicalFont familyName: 'Source Code Sans' pointSize: 12). > > I tried to avoid to convert a text into a string... > > 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.

Feb. 24, 2016