- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Why implementors are getting all the text red?

by Marcus Denker

Very nice! I will check. > On 24 Feb 2016, at 12:40, Guille Polito <guillermopolito(a)gmail.com> wrote: > > I put a slice in the inbox with a patch that seems to solve this. I duplicated some methods, so it should be reviewed/enhanced. But right not I have a meeting and I cannot continue to work on this until tomorrow. > > On 02/24/2016 12:20 PM, Marcus Denker wrote: >> It is a bug. >> >> The alternative would be to continue to have the build failing on the CI often and the check of new submissions >> 8 out of 10 timesâ¦ honestly it was not possible to continue with a broken setup like that. >> >> https://pharo.fogbugz.com/f/cases/17684/highlighting-broken-in-message-list… <https://pharo.fogbugz.com/f/cases/17684/highlighting-broken-in-message-list…> >> >> We need to fix this next. >> >> Marcus >> >>> On 24 Feb 2016, at 12:12, stepharo <stepharo(a)free.fr> <mailto:stepharo@free.fr> wrote: >>> >>> hi >>> >>> May be this is a well known bug but now all the implementors are showed in red. >>> So I cannot film that. >>> >>> Stef >>> >>> <edehdbdi..png> >> >

Feb. 24, 2016

Re: [Pharo-dev] Why implementors are getting all the text red?

by Marcus Denker

Ah, of course there is a workaround to get back the old behaviour: RubShoutStylerDecorator>>style: remove the aText size < 1000 ifTrue: [ ^ self styler style: aText ]. after that it again styles everything in the background, which hides the bug. Marcus > On 24 Feb 2016, at 12:20, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > It is a bug. > > The alternative would be to continue to have the build failing on the CI often and the check of new submissions > 8 out of 10 timesâ¦ honestly it was not possible to continue with a broken setup like that. > > https://pharo.fogbugz.com/f/cases/17684/highlighting-broken-in-message-list… > > We need to fix this next. > > Marcus > >> On 24 Feb 2016, at 12:12, stepharo <stepharo(a)free.fr> wrote: >> >> hi >> >> May be this is a well known bug but now all the implementors are showed in red. >> So I cannot film that. >> >> Stef >> >> <edehdbdi..png> >

Feb. 24, 2016

Re: [Pharo-dev] Why implementors are getting all the text red?

by Guille Polito

I put a slice in the inbox with a patch that seems to solve this. I duplicated some methods, so it should be reviewed/enhanced. But right not I have a meeting and I cannot continue to work on this until tomorrow. On 02/24/2016 12:20 PM, Marcus Denker wrote: > It is a bug. > > The alternative would be to continue to have the build failing on the CI often and the check of new submissions > 8 out of 10 timesâ¦ honestly it was not possible to continue with a broken setup like that. > > https://pharo.fogbugz.com/f/cases/17684/highlighting-broken-in-message-list… > > We need to fix this next. > > Marcus > >> On 24 Feb 2016, at 12:12, stepharo <stepharo(a)free.fr> wrote: >> >> hi >> >> May be this is a well known bug but now all the implementors are showed in red. >> So I cannot film that. >> >> Stef >> >> <edehdbdi..png> >

Feb. 24, 2016

[Bloc] stroke width and layout measure

by Glenn CavarlÃ©

Hi, The stroke width of an element's shape is not taken into account when the child elements are measured. In fact, a child element that matches parent extent hides the left and top borders of its parent. Will it mandatory to use a padding to fix that ? Or is it just part of the work that still to be done ? Regards, ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/Bloc-stroke-width-and-layout-measure-tp4880292.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 24, 2016