- Pharo-dev - lists.pharo.org

[Pharo 9.0] Build #12: FAILURE

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #12 was: FAILURE. Could not extract further issue information from commit message: Merge branch 'Pharo9.0' of github.com:pharo-project/pharo into Pharo9.0 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 20, 2020

[Mm10s] 2010-01-20

by tesonep＠gmail.com

### Last week: - Fix Issue #5434: Settings - Fix Issue #5474: Logging messages with Metacello - Fix Issue #5481: Metacello-logs-now-prints-lots-of-new-lines - [VM] Example of branding VM and signed image in OSX / Win32 - [VM] Improving the Documentation of the PharoVM repository. - [Doc] Pass on the uFFI booklet (Chapters 1 & 2) - Traits Paper - Deadlock in Idle (Windows) - [Pharo8] Buffer error in Sources. Check a problem with large installations and the changes files - [VM] Documenting GC, participating in the GC code dojo. - [VM] Deadlock in Idle (Unix) (MMap location) - [VM] Uploading Latest VM for Pharo 7/8/9 - [Pharo8] Fixing broken tests in Enlumineur - [Pharo8] Integrating a preview of Enlumineur (not available by default) - [Iceberg] New release of Iceberg (v1.6.5): - Speed improvements for loading bigger packages - Local directory relative repositories - Fixes in the Edit project dialog - Adding default values to system settings. - Adding Generic git repository in Metacello. - [Release] Prepare release notes - [Release] Prepare release mail - [Release] Organise issues that will enter in P8. - [FFI] Check FFI changes by Guille - Add Pharo9 to SmalltalkCI ### This week (idea....): - [VM] Fixing Tests in Idle - [Doc] Adding type Table to uFFI booklet - [Doc] Pass on VM booklet - [VM] SDL Plugin for Idle - [VM] Documenting GC, participating in the GC code dojo. - [VM] Improving Speed of TFFI - [VM] Writing tests for JIT generation - [Doc] Techtalk Iceberg - FOSDEM preparation -- Pablo Tesone. tesonep(a)gmail.com

Jan. 20, 2020

Re: [Pharo-dev] printing Symbol

by Sven Van Caekenberghe

#foo printString. '#foo' String streamContents: [ :out | out print: #foo ]. '#foo' String streamContents: [ :out | out << #foo ]. 'foo' I would not use #storeOn: directly, I would consider the fact that String>>#printOn: uses it an implementation detail, and a confusing one at that. > On 20 Jan 2020, at 03:54, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > >> On Jan 19, 2020, at 1:50 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> ï»¿ >> The idea that is that I would like to be able to >> >> text -> tokens -> text >> >> For text -> tokens >> >> (RBScanner on: 'self classVariables: { #A . #B }' readStream) >> contents collect: #value >> >> >> I wrote a little method that takes the result of the RBScanner and recreate the text >> But I cannot get this method to work. >> Iâm puzzled because the symbols are eaten. >> >> >> expressionStringFrom: aLine >> >> "self new >> expressionStringFrom: #('self' 'classVariables:' ${ #A $. #B $}) >> >>> >> 'self classVariables: { A . B }' >> " >> ^ String streamContents: [ :s | >> aLine >> do: [ :each | s << each ] >> separatedBy: [ s space ]] >> >> I tried with print:, printOn:, but I failed. >> >> Any idea? > > With Symbols one needs to use storeOn: > >> >> S. >> >> >> >> >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr / http://www.pharo.org >> 03 59 35 87 52 >> Assistant: Julie Jonas >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France

Jan. 20, 2020

[Mm10s] 2020-01-20

by Esteban Lorenzano

### Last week: - [Spec2] fix a problem with SpDemoActionBarPresenter: we shouldn't use inform from morphic in a gtk application. - [Spec2] make work the cmd+s and escape in dialogs - [Spec2] add a fadeout timer to GtkInfoBar to auto hide the bars. This is to simulate how growl works now (WIP). - [Spec2] fixed toggle checkbox on tables on gtk (it was not implemented) - [Voyage] unqlite: fixed a test that was crashing (a callback was passing 0 instead NULL) - [Release] modify website - [Release] prepare zeroconf - [Release] work on fixing the load of packages problem (the fix was actually done by Pablo) - [Release] merge new PR to integrate Spec2 0.2.0 ### This week - [Release] <â This. - [VM] Check a problem with large installations on AIO/Threaded VM. - Prepare work to make Pharo usable on big images ### Pipeline - [VM] debug AIO and worker thread VMs on linux and windows. - Speed up calypso?

Jan. 20, 2020

Re: [Pharo-dev] Wrong behavior of receiveDataInto:fromHost:port:

by Sven Van Caekenberghe

I am confused, you talk about three different methods, receiveDataInto:fromHost:port: receiveUDPData:toHost:port: sendUDPData... (unspecified) which one do you want to change and how ? In any case, as answered by the primitives, the address seems to be a byte array. So for filtering incoming packets, I would not convert each packet's address, but the target address. > On 20 Jan 2020, at 10:10, HilaireFernandes <hilaire(a)drgeo.eu> wrote: > > IMHO, this method is usefull when you are connected to a networked service > (IP and PORT). It helps to filter the datagrams you are interested by. How would you have a setup where you need to do that ? Are you building a firewall ? Can you elaborate on what you are trying to do ? You do not have to answer, but I am interested in learning where this comes from. > Turning SocketAdress as ByteArray could help without the need to convert > each IP ByteArray instance, as I proposed. Not sure about the implication, > though. > > Hilaire > > > > ----- > http://drgeo.eu > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Jan. 20, 2020

Re: [Pharo-dev] Wrong behavior of receiveDataInto:fromHost:port:

by HilaireFernandes

IMHO, this method is usefull when you are connected to a networked service (IP and PORT). It helps to filter the datagrams you are interested by. Turning SocketAdress as ByteArray could help without the need to convert each IP ByteArray instance, as I proposed. Not sure about the implication, though. Hilaire ----- http://drgeo.eu -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 20, 2020

Re: [Pharo-dev] printing Symbol

by Eliot Miranda

> On Jan 19, 2020, at 1:50 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > ï»¿ > The idea that is that I would like to be able to > > text -> tokens -> text > > For text -> tokens > > (RBScanner on: 'self classVariables: { #A . #B }' readStream) > contents collect: #value > > > I wrote a little method that takes the result of the RBScanner and recreate the text > But I cannot get this method to work. > Iâm puzzled because the symbols are eaten. > > > expressionStringFrom: aLine > > "self new > expressionStringFrom: #('self' 'classVariables:' ${ #A $. #B $}) > >>> > 'self classVariables: { A . B }' > " > ^ String streamContents: [ :s | > aLine > do: [ :each | s << each ] > separatedBy: [ s space ]] > > I tried with print:, printOn:, but I failed. > > Any idea? With Symbols one needs to use storeOn: > > S. > > > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France >

Jan. 20, 2020

Re: [Pharo-dev] Object>>#pinInMemory performance

by Eliot Miranda

Hi Alex, > On Jan 19, 2020, at 3:20 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > ï»¿ > Hello > > I stumbled across a performance issue when pinning objects in memory. > Below I have two scripts that pin and unpin a byte array (or any object) 20k times. > > The first script pins each time a new byte array: >> [ 20000 timesRepeat: [ >> | array wasPinned | >> array := ByteArray new. >> wasPinned := array pinInMemory. >> array setPinnedInMemory: wasPinned. >> ] ] timeToRunWithoutGC. "4284" > > while the second one pins the same instance of array: >> array := ByteArray new. >> [ 20000 timesRepeat: [ >> | wasPinned | >> wasPinned := array pinInMemory. >> array setPinnedInMemory: wasPinned. >> ] ] timeToRunWithoutGC "12" > > > However, as you can see there is a huge performance difference between these scripts. > > Is it expected or is it a bug? And if it is expected what can be happening in VM that leads to such huge performance impact? Thanks! Alas this is expected. The Spur heap is composed of two very different regions, new space and old space. New space is a conventional eden plus two survivor semi spaces in which most objects are allocated and which is garbage collected using generation scavenging. Old space is a segmented space, garbage collected using a mark sweep compact collector. The old space compactor does not move pinned objects, sliding unpinned objects around pinned objects as it compacts. The system tries to maintain one old space segment that contains all pinned objects, but this can be defeated by pinning a few very large objects or pining many objects. The generation scavenger has no support for pinned objects. So what the system does when asked to pin an object in new space is to allocate a copy of the object in old space with the pinned bit set, if possible in the preferred pinned object segment, and become forward the new space object to the pinned copy. Once an object is in old space all that needs to happen to pin (or unpin) an object is set (or clear) the pinned bit in the object header, which is tested by the compactor. HTH > Cheers, > Alex Eliot _,,,^..^,,,_ (phone)

Jan. 20, 2020

Object>>#pinInMemory performance

by Aliaksei Syrel

Hello I stumbled across a performance issue when pinning objects in memory. Below I have two scripts that pin and unpin a byte array (or any object) 20k times. The first script pins each time a new byte array: > [ 20000 timesRepeat: [ > | array wasPinned | > array := ByteArray new. > wasPinned := array pinInMemory. > array setPinnedInMemory: wasPinned. > ] ] timeToRunWithoutGC. *"4284"* while the second one pins the same instance of array: > array := ByteArray new. > [ 20000 timesRepeat: [ > | wasPinned | > wasPinned := array pinInMemory. > array setPinnedInMemory: wasPinned. > ] ] timeToRunWithoutGC "*12*" However, as you can see there is a huge performance difference between these scripts. Is it expected or is it a bug? And if it is expected what can be happening in VM that leads to such huge performance impact? Thanks! Cheers, Alex

Jan. 19, 2020

Re: [Pharo-dev] Wrong behavior of receiveDataInto:fromHost:port:

by Sven Van Caekenberghe

Hi Hilaire, Given the following comment: Socket>>#primSocket: socketID receiveUDPDataInto: aStringOrByteArray startingAt: startIndex count: count "Receive data from the given socket into the given array starting at the given index. Return an Array containing the amount read, the host address byte array, the host port, and the more flag" <primitive: 'primitiveSocketReceiveUDPDataBufCount' module: 'SocketPlugin'> self primitiveFailed I would says that the primitive result uses a ByteArray to represent the (other party's) host address in its second slot. I find the method Socket>>#receiveDataInto:fromHost:port: quite weird: why would you restrict from whom you receive datagrams, especially since non-matching datagrams are simply thrown away. But I do agree that SocketAddress is a weird class, maybe its #species should be set to ByteArray so that #= would work between them, but I am not sure. Sven > On 19 Jan 2020, at 20:24, HilaireFernandes <hilaire(a)drgeo.eu> wrote: > > Hello, > > I would like to discuss one point regarding this method. In my opinion its > parameter hostAddress is expected to be a SocketAdress, but the method > interprets it as a ByteArray. So in the code bellow, the returned result is > 0, although the host responds a datagram: > > server := NetNameResolver addressForName: 'localhost'. > socket := Socket newUDP. > socket sendUDPData: packet toHost: server port: 30000. > socket waitForData. > packet := ByteArray new: 200. > result := socket receiveDataInto: packet fromHost: server port: 30000. > > The method receiveUDPData:toHost:port: should be amended as follow to make > it symmetric with sendUDPData... : > > [ | datagram | > datagram := self receiveUDPDataInto: aStringOrByteArray. > ((datagram at: 2) *asSocketAddress* = hostAddress and: [ (datagram at: 3) > = portNumber ]) > ifTrue: [ ^ datagram at: 1 ] > ifFalse: [ ^0 ] ] repeat > > What do you think? > > > > ----- > http://drgeo.eu > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Jan. 19, 2020