- Pharo-dev - lists.pharo.org

build pharo vm on windows (old mingw package)

by Nicolai Hess

I managed to trash my mingw build environment -> uninstalled /removed mingw/mingsys -> reinstall from current mingw-installer -> bad idea I can build a pharo windows vm but it immediately crashes on startup. I suspect some changes between gcc 4.6 (old environment) gcc 4.8 (new environment). (I think there are some changes related to file globbing (I managed to get the vm somehow working to not crash on startup but on shutdown instead - with _CRT_glob = 0. And gcc-4.8 uses dfferent (dwarf vs. sjlj ) exception handling, don't know if this is related). I tried to find a ming-installer for the old version but could not find anything and I tried to manually setup a ming installation from the old packages (dozen of packages for mingw / core-utils / bintutils /msys from different places (no fun)). 1) did anyone get a windows vm from mingws current version (with gcc 4.8) working? 2) can someone package/zip and upload an old mingw installation (maybe that one that is used on the build server? regards nicolai

April 30, 2015

[pharo-project/pharo-core]

by GitHub

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

April 30, 2015

[pharo-project/pharo-core] c6dbf5: 50023

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c6dbf51eab159861fc2cb0d353da21b09b1d0d6d https://github.com/pharo-project/pharo-core/commit/c6dbf51eab159861fc2cb0d3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-30 (Thu, 30 Apr 2015) Changed paths: A Kernel.package/DelayWaitTimeout.class/instance/waiting/waitOnCompletion_onTimeout_.st R Kernel.package/Object.class/instance/introspection/writeToSlot_of_.st A Kernel.package/Semaphore.class/instance/communication/waitTimeoutSeconds_onCompletion_onTimeout_.st A KernelTests.package/SemaphoreTest.class/instance/tests/testWaitTimeoutSecondsOnCompletionOnTimeout.st M OpalCompiler-Core.package/extension/RBProgramNode/instance/doSemanticAnalysis.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script631.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script632.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50022.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50023.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Shout.package/SHTextStyler.class/instance/styling/styleInBackgroundProcess_.st Log Message: ----------- 50023 15422 SHTextStyler>>#styleInBackgroundProcess: should not set the text if styling process was terminated https://pharo.fogbugz.com/f/cases/15422 15443 AST based highlighter: DNU sometimes https://pharo.fogbugz.com/f/cases/15443 15437 remove writeToSlot:of: https://pharo.fogbugz.com/f/cases/15437 http://files.pharo.org/image/50/50023.zip

April 30, 2015

Re: [Pharo-dev] Class Comment Template Suggestion

by phil＠highoctane.be

I like to use: Provides .... or Enables ... It is all about focusing on the responsibilities and collaborators. The first C is already what I am documenting. So I do not write the name of the class in the comment. As I reuse/refactor names tend to get wrong. Le 29 avr. 2015 16:07, "Ben Coman" <btc(a)openinworld.com> a Ã©crit : > +1 -- I always liked the first person feel I got from Smalltalk class > comments. You might add something like comments should be written in "first > person from the perspective of the class" > > -0.5 -- Maybe the third person CRC style is better for external > documentation (?) > > cheers -ben > > On Wed, Apr 29, 2015 at 9:17 PM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> The class comment template begins: "For the Class part: State the name of >> the class with one line description: For example, I'm xxx the root of the >> hierarchy of visitor objects." >> >> Unlike a traditional CRC card, we are already in a live programming >> environment with good tools! So the class name is duplicated info (the >> browser already shows this) which will have to be manually changed on a >> class rename. Also, the specific example provides an implementation detail >> duplicated by the class hierarchy tree already shown in the browser. I'd >> like to change it to: "For the Class part: State a one line summary. For >> example, "I represent a paragraph of text."" >> >> Any objections? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Class-Comment-Template-Suggestion-tp4822890.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

April 30, 2015

Re: [Pharo-dev] Tx: Bold Text

by Sean P. DeNigris

Nicolas Cellier wrote >> If the font is in the system Eureka! This is the key: if the font is *not* in the system, the requested emphasis does not get carried over to the fallback font. Changing from 'Tahoma' to 'Source Sans Pro' did the trick. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Tx-Bold-Text-tp4822964p4823055.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 30, 2015

Re: [Pharo-dev] Rectangle Center

by Ben Coman

On Thu, Apr 30, 2015 at 4:53 AM, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > > On Wed, Apr 29, 2015 at 5:42 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >> Ok, can we start form the test? >> >> Is it ok, that the test passes for rectangle with 10 @ 20 extent and >> fails for 15 @ 20 extent? >> >> > I would make it test both coordinates. > > i.e. test for 15 @ 15 extent > That would be 15@20 and 20@15. :) cheers -ben

April 29, 2015

Re: [Pharo-dev] TimeStamp deprecation and related frameworks (GLORP, Grease, Magritte, Seaside...)

by Esteban A. Maringolo

I uploaded a new development version (1.12) to the ConfigurationOfGlorp available at DBXTalk/Configurations repo that replaces the references to TimeStamp by DateAndTime. If anybody is willing to test it we can bless it as #stable. I used it and ran my tests against it and it caused no side effects so far. Esteban A. Maringolo 2015-04-29 15:36 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > 2015-04-29 12:49 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> On 29 Apr 2015, at 17:39, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> In the case of GLORP, which I'm updating too, TimeStamp use is more >>> extended, because it's also a datatype used to map table columns, but >>> using no timezone offset. I guess if we move to DateAndTime we should >>> preserve that behavior in order to not break anything. > >> I don't understand this last point, could you elaborate ? > >> As far as I see it, there is nothing TimeStamp did that DateAndTime cannot do. > > Me neither. But I simply don't wan't to break anything. :) > >>> ps: I'm so tempted to fork from the GLORP package, rename as something >>> else (PLORM?) and refactor it mercilessly. >> That is something else ;-) > > :)

April 29, 2015

Re: [Pharo-dev] Rectangle Center

by Sergio Fedi

On Wed, Apr 29, 2015 at 5:42 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Ok, can we start form the test? > > Is it ok, that the test passes for rectangle with 10 @ 20 extent and fails > for 15 @ 20 extent? > > I would make it test both coordinates. i.e. test for 15 @ 15 extent

April 29, 2015

Re: [Pharo-dev] Rectangle Center

by Yuriy Tymchuk

Ok, can we start form the test? Is it ok, that the test passes for rectangle with 10 @ 20 extent and fails for 15 @ 20 extent? Uko > On 29 Apr 2015, at 19:11, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > 2015-04-29 18:50 GMT+02:00 Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com <mailto:tommaso.dalsasso@gmail.com>>: > > > On 29/04/15 15:18, Sean P. DeNigris wrote: > > Natalia Tymchuk wrote > >> Should it really be like that? > > > > The problem is that you can't have half-a-pixel if a dimension is odd > > > > For these situations, I would use the method #floor or #rounded of the > class Point, or create the method #roundedCenter, as Natalia suggested. > > Currently, the name of the class and the method communicate the wrong > behavior. > > Tommaso > > > Rectangle was and still is a primitive type known to low level graphics operations. > It's just that it pre-empts a word that is more generic than the implementation ;) > > You can't even rotate a rectangle... > It's just a clipping or viewport rectangle having same orientation as a rectangular target canvas (image, bitmap, screen or other device). > > Depending on what you are after, it's maybe not the right abstraction... > > That does not mean that Rectangle can't be changed. > That means that it must be carefully changed as long as it is used for the low level stuff... > > ...or it must be split. Maybe it's where namespaces might help. > > Nicolas > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: http://forum.world.st/Rectangle-Center-tp4822883p4822891.html <http://forum.world.st/Rectangle-Center-tp4822883p4822891.html> > > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>. > >

April 29, 2015

Re: [Pharo-dev] Tx: Bold Text

by Nicolas Cellier

2015-04-29 21:32 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-04-29 18:04 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > >> Nicolai Hess wrote >> > Assign the proper Attribute? >> >> Well AFAICT there is no bold attribute, > > > Ah yes, I mix up this with TextMorph and addAttribute:TextEmphasis.... > > >> but I tried setting the font to bold >> via "(LogicalFont familyName: 'Tahoma' pointSize: 9 + i) emphasis: 1; >> yourself." but it was rendered the same as before... >> >> > If the font is in the system, this should work. > > | text font1 font2 font3 string1 | > font1 := (LogicalFont familyName: 'Tahoma' pointSize: 25) emphasis: > TextEmphasis normal emphasisCode. > font2 := (LogicalFont familyName: 'Tahoma' pointSize: 25) emphasis: > TextEmphasis bold emphasisCode. > font3 := (LogicalFont familyName: 'Tahoma' pointSize: 25) emphasis: > TextEmphasis italic emphasisCode. > If an emphasisCode is used at low level, that's fine, but shouldn't the API be more straight like: emphasis: aTextEmphasis or: emphasisCode: anIntegerOrSymbolOrLetterOrAnyOtherWayToCodeAnEmphasis Nicolas string1 := 'Normal Bold Italic '. > text := TxModel new. > text at: text startPosition insert: string1. > > (text startPosition selectTo: text startPosition + 7) > applyAttribute: (TxForeColorAttribute with: Color red); > applyAttribute: (TxFontAttribute with: font1). > > (text startPosition + 7 selectTo: text startPosition + 12) > applyAttribute: (TxForeColorAttribute with: Color green); > applyAttribute: (TxFontAttribute with: font2). > > (text startPosition + 12 selectTo: text startPosition + 18) > applyAttribute: (TxForeColorAttribute with: Color blue); > applyAttribute: (TxFontAttribute with: font3). > > TxTextEditorMorph openInWindowWithText: text > > > > > > >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Tx-Bold-Text-tp4822964p4822987.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

April 29, 2015