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

[Ronie Salgado]

Hi,

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.
>
Now I am building in Windows using both, MinGW version 4.9.3, and Visual
Studio 2015 Community Edition.

I got working pharo,exe -headless Pharo-minimal.image eval "1+1" (the
-headless parameter is for the image to quit after finishing).
When running a normal Pharo.image, I am getting a FFI related crash (with
Visual Studio and MinGW), when the image tries to read the APPDATA
environment variable.

Right now I am using the same main function for both, the Unix and Win32
VM. This means, that we are close of having the embedded version.

In windows I am build two variants of the VM, pharo.exe (or squeak.exe) and
pharow.exe (or squeakw.exe). The executable without the w is a console
program, so it can use stdin, stdout and stderr. The executable with the w
is a windows program that does not create a console window on startup, but
it cannot use stdout, stderr, or stdin. This is the standard workaround for
an annoying limitation of Windows itself (Python does the same in windows,
with the same nomenclature).

Visual Studio is unstable than MinGW, but it has an excellent debugger.
With Visual Studio, I am getting some false positives for an assertion
because they get miscompiled. For some reason, the
assert(GIV(remapBufferCount) == 0) gets compiled into the same as
assert(GIV(remapBufferCount)). Apart from this assertion, these two
versions of the VM are crashing in the same place.


> Fantastic, except:
>
>
> - Unified standard CMake building scripts for Unixes. I hate autoconf. I
> want to use them in Windows too.
>
>
> We have agreed that we will use makefiles and restrict make to generating
> platform config.h files that define platform facilities.  I have very good
> reasons for doing this.  I have discussed this at length this year.  Please
> don't make me argue this all over again.
> ...
> [goodness deleted]
>
I cannot just use makefile, because I am also compiling in Windows using
Visual Studio 2015 Community Edition, by generating the visual studio
projects with CMake. I looked for the older discussions on the mailing
lists, I could not find, a long discussion on the mailing list, except for
several short ones.
I have also seen some projects(LLVM, Boost) that have more than one build
system, an official based on autoconf(or something else), and an
alternative based on CMake.

As for the config.h, I can also generate it using CMake, and I will start
doing it now because I think that it is related to the FFI crashing issues
that I am experimenting on Windows. Currently I am already using CMake for
generating the git version string. As long as git is in the path and cmake
founds it, the header with the version string is generated correctly, even
when using the Visual Studio projects.

Anyway, I am not using the old CMakeVMMaker that Igor did(and I just
learned about Ian CMake work by finding in the mailing list). I just
adapted the plain CMake scripts that I normally use for building my own
projects to build the VM.

  Are you on board?  Would you like to discuss this on skype or somewhere?

Sure we can discuss it, I am on chile so we are not far apart in time zones.

As long as building the VM can be done automatically in Unixes by running a
short number of commands, that work most of the time, I am OK with it.
As for Windows, it has to be possible to use Visual Studio in addition to
MinGW or Cygwin. Visual Studio is required to be able to build for the
Universal Windows Platform, and getting the VM working in a retail XBox One
( https://msdn.microsoft.com/en-us/windows/uwp/xbox-apps/index ).

Best regards,
Ronie

2016-11-26 14:09 GMT-03:00 Eliot Miranda :

>
> Hi Roni,
>
>
> On Nov 23, 2016, at 11:12 PM, 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:
>
>
> Fantastic, except:
>
>
> - Unified standard CMake building scripts for Unixes. I hate autoconf. I
> want to use them in Windows too.
>
>
> We have agreed that we will use makefiles and restrict make to generating
> platform config.h files that define platform facilities.  I have very good
> reasons for doing this.  I have discussed this at length this year.  Please
> don't make me argue this all over again.  Are you on board?  Would you like
> to discuss this on skype or somewhere?
> ...
> [goodness deleted]
>
> Does it make sense, to always trying to create a display in startup time?
>
>
> Good question.  The answer should be "no" but that only makes sense if the
> system is written to not depend on a display when in headless mode.
>
>
> Best regards,
> Ronie
>
>
>

Re: [Pharo-dev] feature request for GTSUnitDebugger

[Denis Kudriashov]

2016-11-26 20:55 GMT+01:00 Andrei Chis :

> Right now there is 'Jump to test method' in the toolbar menu of the stack
> (the drop down arrow next to Through).
>

Thank's for hint


> Could maybe make sense to make it an actual button.
>

I think it would be usefull

[Pharo-dev] Is extract method still working?

[stepharo]

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.


--

Re: [Pharo-dev] feature request for GTSUnitDebugger

[Andrei Chis]

Hi,

Right now there is 'Jump to test method' in the toolbar menu of the stack
(the drop down arrow next to Through).
Could maybe make sense to make it an actual button.

Cheers,
Andrei

On Sat, Nov 26, 2016 at 8:23 PM, Denis Kudriashov 
wrote:

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

[Pharo-dev] feature request for GTSUnitDebugger

[Denis Kudriashov]

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

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

[Eliot Miranda]

Hi Roni,


> On Nov 23, 2016, at 11:12 PM, 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:

Fantastic, except:

> 
> - Unified standard CMake building scripts for Unixes. I hate autoconf. I want 
> to use them in Windows too.

We have agreed that we will use makefiles and restrict make to generating 
platform config.h files that define platform facilities.  I have very good 
reasons for doing this.  I have discussed this at length this year.  Please 
don't make me argue this all over again.  Are you on board?  Would you like to 
discuss this on skype or somewhere?
...
[goodness deleted]

> Does it make sense, to always trying to create a display in startup time?

Good question.  The answer should be "no" but that only makes sense if the 
system is written to not depend on a display when in headless mode.

> 
> Best regards,
> Ronie

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

[stepharo]

Hi doru


Hi Stef,

Would it make sense to put the collection extensions from Moose in the  
Container project?


If you think it make sense. Yes.

For example Ropes could be managed there.
Have a look I have tiny packages.
The idea is to make sure that
	- people can use one abstraction and not be forced to load a complete  
library

- document them with tests and others
	- gather most of collections in one place to make sure that we do not  
lose energy reimplementing them.


I'm packaging the collection from the image that have no users in the  
image for now.

Then I will continue to package
a Tree package (I tried to contact his author but may be he passed away)
SkipList
Quadtrees.

Stef



Cheers,
Doru



On Nov 26, 2016, at 12:11 PM, stepharo  wrote:

Hi Sven

I'm collecting alternative Collection implementations in the project  
Container

I do not remember if I have linkedList but we can add it there.

You may wonder why I'm doing that?
	- I want to be able to have strong collections that are independent  
from the kernel
	- Ideally the kernel of Pharo should be mininmal so it means that I  
would like to

have as few as possible as collections inside the bootstrapped kernel
and that other collections are nicely packaged in Container.

Now I can understand that others do not like what I'm doing but I will  
just continue.

I have Grid, LinkedList, DoubleLinkedList,
I have on my disc
two implementation of Trees
I should harvest BTrees and SkipList.

If people want to help they are welcome, else I will just do it alone.

Stef


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





--
Using Opera's mail client: http://www.opera.com/mail/



--
www.tudorgirba.com
www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be  
done."






--
Using Opera's mail client: http://www.opera.com/mail/

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

[Tudor Girba]

Hi Stef,

Would it make sense to put the collection extensions from Moose in the 
Container project?

Cheers,
Doru


> On Nov 26, 2016, at 12:11 PM, stepharo  wrote:
> 
> Hi Sven
> 
> I'm collecting alternative Collection implementations in the project Container
> I do not remember if I have linkedList but we can add it there.
> 
> You may wonder why I'm doing that?
>   - I want to be able to have strong collections that are independent 
> from the kernel
>   - Ideally the kernel of Pharo should be mininmal so it means that I 
> would like to
>   have as few as possible as collections inside the bootstrapped kernel
>   and that other collections are nicely packaged in Container.
> 
> Now I can understand that others do not like what I'm doing but I will just 
> continue.
> I have Grid, LinkedList, DoubleLinkedList,
> I have on my disc
>   two implementation of Trees
>   I should harvest BTrees and SkipList.
> 
> If people want to help they are welcome, else I will just do it alone.
> 
> Stef
> 
>> 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
>> 
>> 
> 
> 
> -- 
> Using Opera's mail client: http://www.opera.com/mail/
> 

--
www.tudorgirba.com
www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

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

[stepharo]

I added to the CT package


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





--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] Seaside / Getting Started

[Nicolai Hess]

2016-11-26 12:06 GMT+01:00 Nicolai Hess :

> Hi,
>
> I am currently reviewing the Seaside chapter of "Pharo By Example 5".
>
> (more questions will follow)
>

More questions:
>From the book: "You can put Seaside into deployment mode using either the
configuration page (navigate to the entry for the application and click on
the Configure link) or click the Configure button in the toolbar."

I see this configuration linke:
(configure_environment.PNG)
but disabling the development toolbar option, does not seem to make any
difference:
(configer_development.PNG)
(even after starting a new session).

the only way I found is to remove the inherited tool decoration
tool_decoration.PNG

>From the book:"You can also set the mode globally by evaluating
WAGlobalConfiguration setDeploymentMode or WAGlobalConfiguration
setDevelopmentMode."
But there is now WAGlobalConfiguration, not even any implementor for a
"deploymentmode" message

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

[stepharo]

Hi Sven

I'm collecting alternative Collection implementations in the project  
Container

I do not remember if I have linkedList but we can add it there.

You may wonder why I'm doing that?
	- I want to be able to have strong collections that are independent from  
the kernel
	- Ideally the kernel of Pharo should be mininmal so it means that I would  
like to

have as few as possible as collections inside the bootstrapped kernel
and that other collections are nicely packaged in Container.

Now I can understand that others do not like what I'm doing but I will  
just continue.

I have Grid, LinkedList, DoubleLinkedList,
I have on my disc
two implementation of Trees
I should harvest BTrees and SkipList.

If people want to help they are welcome, else I will just do it alone.

Stef


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





--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] Seaside / Getting Started

[Nicolai Hess]

2016-11-26 12:06 GMT+01:00 Nicolai Hess :

>
> 2. And in the current (3.1) version, there is now login/password request.
> I will remove this from the
> description, but does anyone know how we would enable a login/password
> request for the config page?
>

In 3.1, there is *no* password request.

[Pharo-dev] Seaside / Getting Started

[Nicolai Hess]

Hi,

I am currently reviewing the Seaside chapter of "Pharo By Example 5".

The chapter is about Seaside 3.1 (
http://files.pharo.org/seaside/Seaside-3.1-portable.zip)
But some parts the book refers to has changed, and I am asking here to see
whether my changes/updates will be correct, and for some changes I don't
know what to change.

1. configure seaside:
open http://localhost:8080/seaside/config
*I* think the following description expects this (old 2.8?) version output:
(seaside_284_config.PNG)
but instead, we get:
(seaside_31_config.PNG)

2. And in the current (3.1) version, there is now login/password request. I
will remove this from the
description, but does anyone know how we would enable a login/password
request for the config page?

3. Now, there is a step-by-step description how to add a copy of the
example "counter" as "counter2", but
the config page doesn't look like the description in any way.

I guess the right description would be:
change to the "examples folder" on the right, add push the "Add" buttton on
the top pane
(seaside_31_examples.PNG)
instead of "Add entry point" (can not find this in any config page), we
need to push the Add button and
choose the dispatcher type:
(seaside_31_examples_add.PNG)

finally we need to set the root class ...

Is this correct ?
Is there already a updated documentation that describes this (adding a
counter-example) with the newer interface?

Thanks in advance
nicolai
(more questions will follow)