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

Re: [Pharo-dev] [Vm-dev] Removing most of the windowing code
by Ronie Salgado Nov. 28, 2016

Nov. 28, 2016

Now I found the FFI problem with MinGW , I was missing some old compilation flags on my CMake scripts. I still have to fix this same bug with MSVC, but at least normal Pharo image can eval "1+1" without crashing, and stdout is working properly now in Windows. During the rest of the week I will make this VM variant working completely on Linux, Windows and OS X, with SDL2 and hopefully we will get OSWindow working alot better in Windows and Mac. (In Linux it was already working pretty well, probably because each X connection has its own event queue). Interesting to note Microsoft is moving to Clang [1] to replace their > C1 front-end, which should(?) make cross-platform with OSX and Linux a > bit easier. Anyone know if that means MVSC might be better to use on > its own than using MinGW/Cygwin? > > [1] http://www.theregister.co.uk/2015/10/21/microsoft_promises_ > clang_for_windows_in_november_visual_c_update/ > > cheers -ben In Windows the standard compiler is MSVC, despite it has a poorer quality than gcc/clang. The movement to the clang front-end is something where it is not possible to rely until it becomes stable. It is quite clear that the VM is not meant to be used with MSVC, because it is not being built and tested with it all of the time. However, in some platforms, the only alternative is MSVC. Best regards, Ronie 2016-11-28 0:46 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > > On Mon, Nov 28, 2016 at 5:01 AM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > > > > Ronie, > > > > Is all of this in a branch somewhere so that I can have a look? > > > > For cairo, I think that I can build it with another compiler than MinGW, > it doesn't really matter as it just makes a dll (or well, I can just skip > that and reuse an already built one). > > > > -ltro is the flag that makes the whole thing trips up in GCC5 and > requires additional flags, but adding them just kicked the can down the > road a bit further as they were still unresolved symbols. Need to see why > cairo build gives that but seems a cairo issue that others are facing as > well. May end up building cairo with the old compiler but this defeats the > purpose. > > > > For VS2015, I've got it too and yes, the debugging facilities are much > better, not to mention that the compilation times are much nicer. GCC is > just dog slow on Windows compared to Linux. I read that it was because of > sub-bar fork support in Windows. > > Interesting to note Microsoft is moving to Clang [1] to replace their > C1 front-end, which should(?) make cross-platform with OSX and Linux a > bit easier. Anyone know if that means MVSC might be better to use on > its own than using MinGW/Cygwin? > > [1] http://www.theregister.co.uk/2015/10/21/microsoft_promises_ > clang_for_windows_in_november_visual_c_update/ > > cheers -ben >

1 0

Removing most of the windowing code
by Ronie Salgado Nov. 27, 2016

Nov. 27, 2016

Hello, I am working on removing most of windowing code from the VM, and in trying to unify the platform specific code of the VM. In the MinimalistHeadless branch of https://github.com/ronsaldo/opensmalltalk-vm I made the following changes: - Unified standard CMake building scripts for Unixes. I hate autoconf. I want to use them in Windows too. - Refactoring the Unix entry points. I am trying to remove a lot of code for simplfying stuff. - Null window driver for true headless. - Optional SDL2 based traditional display backend for compatibility reasons, and because the extra Morphic worlds using OSWindow are a bit unstable. So far I managed to run a standard Pharo 6 image using this custom VM in Linux. Windows and Mac are coming next. Hopefully this is going to fix the problems with duplicated events when using OSWindow in Windows. I am also planning on making a standard interface for embedding the VM in an application, at least as a static library. With this new building system, this seems to be easy to do. BTW. When I tried the minimalistic Pharo image, in a completely headless VM, I got the following error: [ "Ugh .... now this is a biggie - a system that does not support any of the display depths at all." Smalltalk logError: 'Fatal error: This system has no support for any display depth at all.' inContext: thisContext. Smalltalk quitPrimitive "There is no way to continue from here" ] in DisplayScreen>>findAnyDisplayDepth DisplayScreen>>findAnyDisplayDepthIfNone: DisplayScreen>>findAnyDisplayDepth DisplayScreen>>setExtent:depth: DisplayScreen class>>startUp As a workaround, I am doing the following for ioHasDisplayDepth with the null driver: sqInt ioHasDisplayDepth(sqInt depth) { return true; } In DisplayScreen class >> startUp we have the following: startUp "DisplayScreen startUp" Display setExtent: self actualScreenSize depth: Display nativeDepth. Display beDisplay Does it make sense, to always trying to create a display in startup time? Best regards, Ronie

10 17

pillar latex and code listings
by Nicolai Hess Nov. 27, 2016

Nov. 27, 2016

How are latex output of (named) code listings supposed to work /look ? I look at the pdf for the update PBE and the references to code example don't work (just show ??, it works for figures). The code in the code example isn't highlight and does't have a dark background (as it is in the html output). The generated tex looks like this: \begin{listing}[caption={Decomposing aPen go: 100 + 20}, label=scr:decColor2, language=smalltalk] aPen go: 100 + 20 (1) 100 + 20 "binary message first" --> 120 (2) aPen go: 120 "then keyword message" \end{listing} the pdf output: Any idea what is wrong ? Is a postprocessing step necessary ? Should it be \begin{lstlisting} instead of \begin{listing} ?

2 9

feature request for GTSUnitDebugger
by Denis Kudriashov Nov. 26, 2016

Nov. 26, 2016

Hello. I catch myself that I very often scroll stack view in debugger just to see test method. It would be nice to have test tab and "show test" button. Best regards, Denis

2 2

Is extract method still working?
by stepharo Nov. 26, 2016

Nov. 26, 2016

Hi on this expression when I select KeyedTree new at: 1 put: '1-3-1'; at: 2 put: '1-3-2'; yourself I get an error because the method extracted look like the following. at: 1 put: '1-3-1'; at: 2 put: '1-3-2'; yourself testSubtrees "Test the subtrees method for success and failure modes." | t1 t2 t3 t4 | t1 := KeyedTree new at: 1 put: (t2 := KeyedTree new at: 1 put: '1-1'; at: 2 put: '1-2'; at: 3 put: (t3 := KeyedTree new at: 1 put: '1-3-1'; at: 2 put: '1-3-2'; yourself); yourself); at: 2 put: '2'; at: 3 put: (t4 := KeyedTree new at: 1 put: '1-3-1'; at: 2 put: '1-3-2'; yourself); yourself. I wonder if something change in the AST. --

1 0

LinkedList>>#containsCycle
by Sven Van Caekenberghe Nov. 26, 2016

Nov. 26, 2016

Hi, There exists a very elegant algorithm to detect cycles in linked lists. https://en.wikipedia.org/wiki/Cycle_detection#Tortoise_and_hare I know that our LinkedList was written with the assumption that there are no cycles. However, it seems to me that it would be nice to have a test to check for cycles. This could be useful while printing or inspecting a LinkedList (and prevent things from blowing up when there is a cycle). Here is the implementation: LinkedList>>#containsCycle | slow fast | slow := fast := firstLink. [ slow notNil and: [ fast notNil and: [ fast nextLink notNil ] ] ] whileTrue: [ slow := slow nextLink. fast := fast nextLink nextLink. slow == fast ifTrue: [ ^ true ] ]. ^ false And one of the tests: LinkedListTests>>#testCycles 1 to: 42 do: [ :each | list := LinkedList withAll: (1 to: each). "Warning: the following statement creates a cylce, inspecting/viewing list will probably fail" list lastLink nextLink: list firstLink. self assert: list containsCycle ] Opinions ? Sven

4 5

roundTo: strange behavior
by stepharo Nov. 26, 2016

Nov. 26, 2016

Hi I'm wondering if we do not have a bug here 12.222222222222221 roundTo: 0.1 "12.200000000000001" 12.222222222222221 roundTo: 0.01 "12.22" Stef

18 69

[Pharo-project] About ~= and ~~
by Clara Allende Nov. 26, 2016

Nov. 26, 2016

Hi guys, I'm wondering, why? ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)." self == anObject ifTrue: [^ false] ifFalse: [^ true] Instead of: ProtoObject>> ~~ anObject "Answer whether the receiver and the argument are not the same object (do not have the same object pointer)." ^(self == anObject) not And why? Object >> ~= anObject "Answer whether the receiver and the argument do not represent the same object." ^self = anObject == false Instead of Object>> ~= anObject "Answer whether the receiver and the argument do not represent the same object." ^(self = anObject) not. Is there any particular reason for this that I'm missing? Thanks in advance! -- "*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*" Linus Torvalds

12 26

[pharo-project/pharo-core]
by GitHub Nov. 25, 2016

Nov. 25, 2016

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

1 0

[pharo-project/pharo-core] e13d19: 50764
by GitHub Nov. 25, 2016

Nov. 25, 2016

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: e13d19f8de0c20da4ae9607cb5b0164a5e4c9e11 https://github.com/pharo-project/pharo-core/commit/e13d19f8de0c20da4ae9607c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-11-25 (Fri, 25 Nov 2016) Changed paths: M Morphic-Base.package/MorphicEventHandler.class/instance/access/methodRefList.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50763.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50764.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50763.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50764.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50764 19361 Morph>>#showActions broken https://pharo.fogbugz.com/f/cases/19361 http://files.pharo.org/image/50/50764.zip

1 0