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

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

by 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 <stepharo(a)free.fr> 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/

Nov. 26, 2016

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

by 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 <stepharo(a)free.fr> 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."

Nov. 26, 2016

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

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

Nov. 26, 2016

Re: [Pharo-dev] Seaside / Getting Started

by Nicolai Hess

2016-11-26 12:06 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > 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

Nov. 26, 2016

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

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

Nov. 26, 2016

Re: [Pharo-dev] Seaside / Getting Started

by Nicolai Hess

2016-11-26 12:06 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > 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.

Nov. 26, 2016

Seaside / Getting Started

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

Nov. 26, 2016

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

by Tudor Girba

+100. Great job! Doru > On Nov 26, 2016, at 9:44 AM, stepharo <stepharo(a)free.fr> wrote: > > This is super coooooool > Embedding the Vm as a static lib is a kind of dream becoming true. > > Stef > > > 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 > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ -- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."

Nov. 26, 2016

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

by stepharo

This is super coooooool Embedding the Vm as a static lib is a kind of dream becoming true. Stef > 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 -- Using Opera's mail client: http://www.opera.com/mail/

Nov. 26, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Martin McClure

On 11/25/2016 08:33 PM, Andres Valloud wrote: > If "rounding" had well specified behavior that was at least somewhat > reasonable (e.g. return the closest floating point value and round to > even if tied), I'd accept floating point results that don't print > "pretty" in base 10. That's the way things are, there's no point in > pretending IEEE-754 is not base 2. > > If "rounding" is being done in place of "printing", or obtaining a > "string representation", I think that won't work as expected because > 0.1 not representable etc. > > For "printing", the algorithms were Dragon4 and Grisu3 last time I > checked. Thanks for the reference! Grisu3 looks interesting. > > For "floating point that works nice in base 10", there's IEEE-854. > For those unfamiliar with the spec, it's been implemented in > non-exotic hardware already. > Base 2 and base 10 are now both covered in IEEE-754 as of the 2008 revision (which also ties up some loose ends that were not specified adequately in IEEE 754-1985) Regards, -Martin

Nov. 26, 2016