- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] roundTo: strange behavior

by Andres Valloud

Hey Martin... I agree on the confusion. > I still recommend not rounding the number itself, but rounding the printing of the number Yes. 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. 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. > you did proof that, as you said "1.2000000000000002 *is* the correct answer for 1.19 roundTo: 0.1.". As a suggestion for these types of problems, try iterating over a floating point bit range converting each to a true fraction and see which one is closest? > testIfCompletelyBroken [doesn't round to even] I'd agree rounding to even would be better. Guillermo, > And also: I'd argue that you NEVER EVER want to use simple Floats for financial applications Define "financial" applications? In the risk management world, tying down that last $1 difference will likely cost more electricity (and way more time) than the $1 is worth. John, > While ANSI says that the numbers should be converted using the default conversion table, all of the Smalltalkâs that Iâve tried donât follow that. Iâve tried Dolphin, VW, Pharo, & VAST, and all return fractions. I prefer this behavior over the ANSI behavior. I agree that ANSI doesn't always make the best sense. If it were up to me, I'd follow the relevant standard to the letter. That's more important than providing a custom interpretation of an interoperability mechanism just for Smalltalk (or a particular dialect) by default. Nicolas, > printShowingDecimalPlaces: That's quite a long selector. Has anyone considered an approach along the lines of this? 1.2345 %f #'3.2' => ' 1.23' 1.2345 %f #'03.2' => '001.23' A reminder: calling printf() via FFI is undefined behavior. Andres. On 10/26/16 23:31 , Martin McClure wrote: > On 10/26/2016 08:27 AM, stepharo wrote: >> So what is the definition of printShowingMaxDecimalDigit:? >> I have the impression that there is a confusion between the rounding a >> number and the printing of his value in a given format. > > Yes, I see quite a bit of confusion in this thread about that. > >> we can deprecate roundTo: if necessary. > > I think roundTo: is OK. #round: is not, and should be deprecated (at > least for Floats). For Floats, the idea of rounding to a specific number > of decimal digits is a fantasy. Here's why: Floats cannot exactly > represent most common decimal fractions. For example: > > 0.1 -- not representable > > 0.2 -- not representable > > 0.3 -- not representable > > 0.4 -- not representable > > 0.5 -- hey, representable! > > 0.6 -- not representable > > 0.7 -- not representable > > 0.8 -- not representable > > 0.9 -- not representable > > 1.0 -- representable. > > *Printing* a Float to a specific rounded decimal format is a sensible > idea, and should be encouraged. But trying for a "rounded Float" > *number* just can't be done exactly (except by converting to a Fraction). > > Fractions can be rounded to exact decimal fractions, so something like > "myFraction roundTo: 1/100" makes sense. But the current implementation > of round: on Fraction that converts to a Float just gets you the misery > detailed above. > > > On 10/26/2016 01:00 PM, Nicolas Cellier wrote: >> I've put a single slice in the inbox for the 3 issues because they all >> are related. >> See slice comment: >> >> For Float, implement guard to prevent overflow (15471), and use exact >> representation for intermediate results (asFraction) so as to avoid >> double rounding problems (15473) > > The double rounding problem is not the fundamental problem, the > fundamental problem is that what is desired does not exist, because > Floats cannot exactly represent most decimal fractions. So this can't > really fix it. > >> >> For Fraction (15472), choose an exact representation for result rather >> than Float. This is because such method is particularly usefull for >> financial/monetary applications. >> > Yes. Fraction or ScaledDecimal. Not Floats, unless the developer > understands the needs of the financial world and the limitations of > Floats very well. > > > Regards, > > -Martin >

Nov. 26, 2016

Re: [Pharo-dev] About ~= and ~~

by Eliot Miranda

Hi Peter, I'd appreciate it if you used reply to all to keep the conversation thread going. > On Nov 25, 2016, at 10:31 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Out of interest... is the single extra dispatch really that expensive? Yes, in the common case where the send of #== is followed by a jump, as it is in ifNil:ifNotNil: or == foo ifTrue: etc. when #== is inclined the following jump is eliminated and the VM jumps on the condition codes for the comparison. When #== is a real send it answers the true or false objects and the following jump must compare this result against true or false. Note that Sista will be able to perform the inclining optimisation so we will get the performance back once Sista is deployed. > > And speaking of object inequality... I would like to propose "<>" instead of "~=", because I never remember on which side ~ should be.. > > Peter > >> On Wed, Nov 23, 2016 at 05:39:03AM -0800, Aliaksei Syrel wrote: >> Hi >> >> It is been a while... >> So, do we want to replace ~~ with a primitive? :) >> >> Cheers >> Alex >> >> >> >> -- >> View this message in context: http://forum.world.st/About-and-tp3898409p4924391.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >

Nov. 26, 2016