Re: [Pharo-dev] Removing most of the windowing code

[p...@highoctane.be]

I am fighting Window VM compilation issues (e.g. Cairo with GCC5.x under
Mingw).
If you have a GCC5 instead of the old 4.6, I am interested in your config.

It is great that you are giving a solid kick in this. Do not get burned out.

Peace.

Phil

On Thu, Nov 24, 2016 at 11:48 PM, Ronie Salgado  wrote:

> Need help with the VM cleaning?
>>
> Not for now. Now I will try to make this working on Windows. Once I manage
> to isolate the most of the stubbed dependencies on Window(heartbeat, time,
> asynchronous I/O), we will have a more unified core VM in a single static
> library. When we have this unified VM, I will need help for testing, and
> defining a definitive build system where the community also agrees. For now
> I will just keep working on my private branch.
>
> 2016-11-24 17:29 GMT-03:00 philippe.b...@highoctane.be <
> philippe.b...@gmail.com>:
>
>> Need help with the VM cleaning?
>>
>> Le 24 nov. 2016 08:13, "Ronie Salgado"  a écrit :
>>
>>> 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/op
>>> ensmalltalk-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
>>>
>>
>

Re: [Pharo-dev] Removing most of the windowing code

[Ronie Salgado]

>
> Need help with the VM cleaning?
>
Not for now. Now I will try to make this working on Windows. Once I manage
to isolate the most of the stubbed dependencies on Window(heartbeat, time,
asynchronous I/O), we will have a more unified core VM in a single static
library. When we have this unified VM, I will need help for testing, and
defining a definitive build system where the community also agrees. For now
I will just keep working on my private branch.

2016-11-24 17:29 GMT-03:00 philippe.b...@highoctane.be <
philippe.b...@gmail.com>:

> Need help with the VM cleaning?
>
> Le 24 nov. 2016 08:13, "Ronie Salgado"  a écrit :
>
>> 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
>>
>

Re: [Pharo-dev] Removing most of the windowing code

[philippe.b...@highoctane.be]

Need help with the VM cleaning?

Le 24 nov. 2016 08:13, "Ronie Salgado"  a écrit :

> 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
>

Re: [Pharo-dev] LinkedList>>#containsCycle

[Max Leske]

Very nice.

In such a case I would like to know, which elements are causing the cycle or, 
alternatively, their positions. Maybe #cyclicElements?

Cheers,
Max

> On 24 Nov 2016, at 15:16, Sven Van Caekenberghe  wrote:
> 
> 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
> 
> 

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] a2dd96: 60306

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: a2dd96f13ddf9e1b2b87c0398e59ac35574dabbb
  
https://github.com/pharo-project/pharo-core/commit/a2dd96f13ddf9e1b2b87c0398e59ac35574dabbb
  Author: Jenkins Build Server 
  Date:   2016-11-24 (Thu, 24 Nov 2016)

  Changed paths:
M 
ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/symbolic 
versions/stable_.st
M 
ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version015_.st
A 
ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version016_.st
A 
ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version017_.st
M 
GT-InspectorExtensions-Core.package/extension/Class/instance/gtInspectorInstanceVariablesIn_.st
M 
GT-InspectorExtensions-Core.package/extension/Class/instance/gtInspectorMethodsIn_.st
M 
Kernel-Tests.package/ClassTest.class/instance/testing/testClassRespectsPolymorphismWithTrait.st
M Kernel.package/Class.class/instance/accessing parallel 
hierarchy/baseClass.st
M Kernel.package/Class.class/instance/accessing parallel 
hierarchy/classClass.st
M Kernel.package/Class.class/instance/accessing/basicLocalSelectors.st
M Kernel.package/Class.class/instance/accessing/basicLocalSelectors_.st
M Kernel.package/Class.class/instance/accessing/traitComposition.st
M Kernel.package/Class.class/instance/accessing/traitComposition_.st
M Kernel.package/Class.class/instance/instance variables/addInstVarNamed_.st
M Kernel.package/Class.class/instance/instance variables/addSlot_.st
M Kernel.package/Class.class/instance/private/addClassSlot_.st
M Kernel.package/Class.class/instance/private/getName.st
M Kernel.package/Class.class/instance/private/setName_.st
M Kernel.package/Class.class/instance/subclass 
creation/newAnonymousSubclass.st
M Kernel.package/Class.class/instance/testing/isClass.st
M Nautilus.package/extension/Class/instance/definitionForNautilus.st
M 
Nautilus.package/extension/Class/instance/definitionForNautilusWithSlots.st
M Polymorph-Widgets.package/extension/Trait/instance/systemIconName.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60305.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60306.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60305.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60306.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
R Tool-Catalog.package/CatalogBrowser.class/instance/Nautilus groups 
support/createGroupWithLoadedPackagesFrom_.st
R Tool-Catalog.package/CatalogBrowser.class/instance/Nautilus groups 
support/installAndCreateGroupButton_.st
R Tool-Catalog.package/CatalogBrowser.class/instance/Nautilus groups 
support/installAndCreateGroupMenuItem_.st
R Tool-Catalog.package/CatalogBrowser.class/instance/Nautilus groups 
support/onInstallAndCreateGroupFrom_.st
M Traits.package/Trait.class/instance/accessing parallel 
hierarchy/baseTrait.st
M Traits.package/Trait.class/instance/accessing parallel 
hierarchy/classTrait.st
M Traits.package/Trait.class/instance/accessing parallel 
hierarchy/classTrait_.st
M Traits.package/Trait.class/instance/accessing parallel 
hierarchy/isBaseTrait.st
M Traits.package/Trait.class/instance/accessing parallel 
hierarchy/isClassTrait.st
M Traits.package/Trait.class/instance/accessing/name_.st
M Traits.package/Trait.class/instance/initialization/initialize.st

  Log Message:
  ---
  60306
19365 remove dependency of Catalog on Nautilus
https://pharo.fogbugz.com/f/cases/19365

19367 testClassRespectsPolymorphismWithTrait does suppose full image
https://pharo.fogbugz.com/f/cases/19367

http://files.pharo.org/image/60/60306.zip

[Pharo-dev] LinkedList>>#containsCycle

[Sven Van Caekenberghe]

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

Re: [Pharo-dev] [Vm-dev] Removing most of the windowing code

[Aliaksei Syrel]

Thanks Ronie!
You are doing a great job! :)

Cheers,
Alex

On 24 November 2016 at 15:06, Ronie Salgado  wrote:

> you cannot unilaterally do this.
>> I hate autoconf too, but in VM list we have a general agreement on how to
>> manage the VM build process, and unless you manage to convince the rest of
>> people working there (and specially Eliot, who works there more than the
>> rest), you have literally zero chance this will be adopted (and then, your
>> work will be a general lose of time…).
>> In any case, you have my vote :)
>>
> This was something that I did for quickly testing and trying to remove the
> windowing code. I also did this, because the building system is not working
> all of the time in my linux machine. The scripts for loading the VMMaker
> image are most of the time not working at all in Linux. I got frustrated by
> not being able on keep working on Lowcode for supporting the 64 bits
> version, because of these problems.
>
> Anyway, I do not care if this part gets integrated or not, as long as I
> can keep working on my stuff, and I don't have a bunch of manully written
> scripts in build.*/* . As long as there is a single script that can be
> configured for each target or flavour of the VM I am okay with it.
>
> Now I will document these scripts:
>
> For setting the flavour of the VM, there are the following options
> - SPUR_OBJECT_MODEL (On by default)
> - SISTA_OPTIMIZER (Off by default)
> - PHARO_BRANDING (On by default)
> - COG_JIT(On by default. If off, it will build a stack interpreter only VM)
>
> There are platform specific check for choosing whether to build a 64 bits
> VM or not. When building in a x86_64 systems, there is the
> BUILD_I386_VERSION option (Off by default) which will set the appropiate
> flags for building a 32 bits VM in a 64 bits system (-m32)
>
> These options are used for making a string with the vm sources
> direction(src ,stacksrc, spursrc, etc) and for selecting the sources of the
> vm. In this experimental branch I am moving some of the sources at
> platform/ barest minimum code for compiling the VM. By the end of this, I should
> probably move back the platform specific sources into their original
> locations.
>
> The plugins to build with the VM are defined in Plugins.cmake (
> https://github.com/ronsaldo/opensmalltalk-vm/blob/
> MinimalisticHeadless/Plugins.cmake)
>
> Most of the time, adding a plugin is just a matter calling a macro:
>
>> # Basic internal plugins
>> add_vm_plugin_auto(FilePlugin INTERNAL)
>> add_vm_plugin_auto(LargeIntegers INTERNAL)
>> add_vm_plugin_auto(LocalePlugin INTERNAL)
>> add_vm_plugin_auto(MiscPrimitivePlugin INTERNAL)
>> add_vm_plugin_auto(SecurityPlugin INTERNAL)
>> add_vm_plugin_auto(SocketPlugin INTERNAL)
>>
>> add_vm_plugin_auto(B2DPlugin INTERNAL)
>> add_vm_plugin_auto(BitBltPlugin INTERNAL)
>>
>> add_vm_plugin_auto(FloatArrayPlugin INTERNAL)
>> add_vm_plugin_auto(FloatMathPlugin INTERNAL)
>> add_vm_plugin_auto(Matrix2x3Plugin INTERNAL)
>>
>> # Basic external plugins
>> add_vm_plugin_auto(SurfacePlugin EXTERNAL)
>>
>
> For more selective plugins, such as the SqueakFFIPrims plugin there is the
> add_vm_plugin_sources macro:
>
>> add_vm_plugin_sources(SqueakFFIPrims EXTERNAL ${SqueakFFIPrims_Sources})
>
>
> Later I will add another macro for linking a library with a plugin, which
> will perform the correct action depending whether the Plugin is internal or
> external. The macros for building a plugin add an option for specifying
> whether to build or not a plugin (e.g: BUILD_PLUGIN_FilePlugin,
> BUILD_PLUGIN_FT2Plugin).
>
> For building the a default VM using cmake, the only commands are required
> in the top level source directory:
>
>> mkdir build_dir
>> cd build_dir
>> cmake ..
>> make
>>
>
> For choosing interactively which options to enable or not, it is possible
> to use cmake-gui instead of cmake in the above sequence of commands. The
> built VM will be placed at build_dir/dist
>
> Currently, I am not using the cmake configure capabilties for generating
> config.h and generating the HAVE_*_H defines. Later I will implement this,
> but taking special care in supporting the cross compilation scenario, where
> it is not possible to execute compiled program for probing the system for
> things such as sizeof(void*).
>
> Could you explain more what traditional display backend means? Because I
>> am probably out of domain but want to know more.
>>
> If the SUPPORT_TRADITIONAL_DISPLAY cmake option is enabled, and cmake
> finds SDL2 (it will look for the SDL2 libraries using the names SDL2-2.0
> SDL2), then a non-headless VM will be built using
> sqPlatformSpecific-SDL2Window.c ( https://github.com/ronsaldo/
> opensmalltalk-vm/blob/MinimalisticHeadless/minheadless/source/
> sqPlatformSpecific-SDL2Window.c ) instead of
> sqPlatformSpecific-NullWindow.c ( https://github.com/ronsaldo/
> opensmalltalk-vm/blob/MinimalisticHeadless/minheadless/source/
> sqPlatformSpecific-NullWindow.c ).
>
> This 

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 5ad156: 60305

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 5ad156a822a9bfed792abdab98f6e00eaefa48de
  
https://github.com/pharo-project/pharo-core/commit/5ad156a822a9bfed792abdab98f6e00eaefa48de
  Author: Jenkins Build Server 
  Date:   2016-11-24 (Thu, 24 Nov 2016)

  Changed paths:
M Files.package/FileStream.class/class/stdio/flushAndVoidStdioFiles.st
M Files.package/FileStream.class/class/stdio/voidStdioFiles.st
R 
Morphic-Core.package/PasteUpMorph.class/instance/dropping%2Fgrabbing/originAtCenter.st
R 
Morphic-Core.package/PasteUpMorph.class/instance/options/toggleOriginAtCenter.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60304.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60305.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60304.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60305.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M Tools-Test.package/MethodFinderTest.class/instance/test 
examples/testSearchForAccessAtOne.st

  Log Message:
  ---
  60305
19295 originAtCenter looks like deadCode
https://pharo.fogbugz.com/f/cases/19295

19372 MethodFinderTest is dependent>>#testSearchForAccessAtOne is dependent on 
result order
https://pharo.fogbugz.com/f/cases/19372

17771 Empty stderr/stdout files should be deleted on image shutdown
https://pharo.fogbugz.com/f/cases/17771

http://files.pharo.org/image/60/60305.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] b058ad: 60304

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: b058adcbfa4fd3463f57a73af89bd4432fa4bbe7
  
https://github.com/pharo-project/pharo-core/commit/b058adcbfa4fd3463f57a73af89bd4432fa4bbe7
  Author: Jenkins Build Server 
  Date:   2016-11-24 (Thu, 24 Nov 2016)

  Changed paths:
R FuelPlatform.package/FLPharo11Platform.class/README.md
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-InflateStream/next_into_startingAt_.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-behavior/methodNamed_.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-class/addInstVarNamed_.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-class/removeInstVarNamed_.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-flbasicserializationtest/expectedFailures.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-flprimitivecluster/registerIndexesOn_.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-flserializationtest/deleteFileNamed_.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-flsubstitutioncluster/add_substitutedBy_traceWith_.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-flsubstitutioncluster/initializeAnalyzing.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-methodcontext/tempNamed_.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-sequenceablecollection/reduceRight_.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-sequenceablecollection/shuffleBy_.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-sequenceablecollection/sum_.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-set/addIfNotPresent_ifPresentDo_.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-weakobjectstest/testAssociationWithWeakFinalizationList.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/private-hacks-metacello/fixMetacello.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/testing/addPackageManifest.st
R 
FuelPlatform.package/FLPharo11Platform.class/class/testing/isResponsibleForCurrentPlatform.st
R FuelPlatform.package/FLPharo11Platform.class/definition.st
R FuelPlatform.package/FLPharo12Platform.class/README.md
R 
FuelPlatform.package/FLPharo12Platform.class/class/private-extensions-InflateStream/next_into_startingAt_.st
R 
FuelPlatform.package/FLPharo12Platform.class/class/private-extensions-behavior/methodNamed_.st
R 
FuelPlatform.package/FLPharo12Platform.class/class/private-extensions-flprimitivecluster/registerIndexesOn_.st
R 
FuelPlatform.package/FLPharo12Platform.class/class/private-extensions-flserializationtest/deleteFileNamed_.st
R 
FuelPlatform.package/FLPharo12Platform.class/class/private-extensions-flsubstitutioncluster/add_substitutedBy_traceWith_.st
R 
FuelPlatform.package/FLPharo12Platform.class/class/private-extensions-flsubstitutioncluster/initializeAnalyzing.st
R 
FuelPlatform.package/FLPharo12Platform.class/class/private-extensions-set/addIfNotPresent_ifPresentDo_.st
R 
FuelPlatform.package/FLPharo12Platform.class/class/testing/addPackageManifest.st
R 
FuelPlatform.package/FLPharo12Platform.class/class/testing/isResponsibleForCurrentPlatform.st
R FuelPlatform.package/FLPharo12Platform.class/definition.st
R FuelPlatform.package/FLPharo13Platform.class/README.md
R 
FuelPlatform.package/FLPharo13Platform.class/class/private-extensions-InflateStream/next_into_startingAt_.st
R 
FuelPlatform.package/FLPharo13Platform.class/class/private-extensions-behavior/methodNamed_.st
R 
FuelPlatform.package/FLPharo13Platform.class/class/private-extensions-flserializationtest/deleteFileNamed_.st
R 
FuelPlatform.package/FLPharo13Platform.class/class/testing/isResponsibleForCurrentPlatform.st
R FuelPlatform.package/FLPharo13Platform.class/definition.st
R FuelPlatform.package/FLPharo14Platform.class/README.md
R 
FuelPlatform.package/FLPharo14Platform.class/class/testing/isResponsibleForCurrentPlatform.st
R FuelPlatform.package/FLPharo14Platform.class/definition.st
R FuelPlatform.package/FLPharo1Platform.class/README.md
R FuelPlatform.package/FLPharo1Platform.class/class/adding/addTraits.st
R 
FuelPlatform.package/FLPharo1Platform.class/class/private-extensions-behavior/fuelIgnoredInstanceVariableNames.st
R 
FuelPlatform.package/FLPharo1Platform.class/class/private-extensions-behavior/fuelInitializeTraitCompositionForBehavior.st
R 
FuelPlatform.package/FLPharo1Platform.class/class/private-extensions-behavior/fuelNew.st
R 
FuelPlatform.package/FLPharo1Platform.class/class/private-extensions-behavior/fuelNew_.st
R 

Re: [Pharo-dev] Running on Ubuntu?

[Igor Stasenko]

On 24 November 2016 at 04:43, Chris Muller  wrote:

> Hey Igor, I was just messing around with this the other day; Levente
> had the tersest incantation which worked on my fresh 14.04.4 install:
>
> sudo dpkg --add-architecture i386
> sudo apt-get update
> sudo apt-get install libuuid1:i386 libglu1-mesa:i386 libsm6:i386
>
> (Documented at http://wiki.squeak.org/squeak/6134).
>
>
yeah... if its fresh.. but i guess my problem was that there was something
installed, that were blocking
clean installation of above libs due  to conflicting dependencies.
anyways, this is not critical for my current needs.
Thanks for attention.


> On Tue, Nov 22, 2016 at 10:46 AM, Igor Stasenko 
> wrote:
> >
> >
> > On 22 November 2016 at 16:50, Sven Van Caekenberghe 
> wrote:
> >>
> >> Igor,
> >>
> >> For future reference,
> >>
> >> > On 22 Nov 2016, at 11:17, Sven Van Caekenberghe  wrote:
> >> >
> >> > (this is what I use for headless)
> >> >
> >> > sudo dpkg --add-architecture i386
> >> > sudo apt-get update
> >> > sudo apt-get install libc6:i386
> >> > sudo apt-get install libssl1.0.0:i386
> >> > sudo apt-get install libfreetype6:i386
> >>
> >> On a fresh Ubuntu 16.04.1 LTS 64-bit I did the above
> >>
> >> > (you might need more for full UI)
> >>
> >> And then just one other install
> >>
> >>  sudo apt-get install libgl1-mesa-glx:i386
> >>
> >> which installed lots of dependencies.
> >>
> >> After that I was able to run the download
> >>
> >>  get.pharo.org/60+vm
> >>
> >> in UI mode (using pharo-ui).
> >>
> >> Sven
> >>
> > ohh.. wait 6.0 is on the sight.. and i was mangling with 5.0..
> > yeah, that explains why it needs 32-bit libs and all that mess  :)
> >
> >
> > --
> > Best regards,
> > Igor Stasenko.
>
>


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] [Vm-dev] Removing most of the windowing code

[p...@highoctane.be]

As Estaban said: wow, a new world opens.

Amazing.

Phil

On Thu, Nov 24, 2016 at 8:24 AM, Esteban Lorenzano 
wrote:

> Hi Ronie,
>
> First, this is super cool! I want this to happen since a lot of time :)
> Second, observation below
>
> On 24 Nov 2016, at 08:12, Ronie Salgado  wrote:
>
> 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.
>
>
> you cannot unilaterally do this.
> I hate autoconf too, but in VM list we have a general agreement on how to
> manage the VM build process, and unless you manage to convince the rest of
> people working there (and specially Eliot, who works there more than the
> rest), you have literally zero chance this will be adopted (and then, your
> work will be a general lose of time…).
> In any case, you have my vote :)
>
> - 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.
>
>
> this is sooo super :)
>
>
> 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.
>
>
> even more super :)
>
> where can I see the code?
>
> Esteban
>
>
> 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
>
>
>