July 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] NeoCSVReader and an empty field at the very end of a file

by Sven Van Caekenberghe

Hi Joachim, First, thanks for the feedback. Second, since you are on a different platform, that might be a factor. Did you test your problem on Pharo itself ? Because there are already unit tests specifically for the case you describe: #testEmptyLastFieldUnquoted #testEmptyLastFieldQuoted These obviously pass for Pharo, do they pass for you ? Maybe your problem case is slightly different though ? Sven > On 01 Jul 2015, at 13:40, jtuchel(a)objektfabrik.de wrote: > > Hi, > > I've tried porting SvenVanCaekenberghe.20 and see the same problems in this version. IN addition to the fix already mentioned, I also had to change readSeparator: > > readSeparator > > ^self atEnd ifFalse: [self peekFor: separator] > > As far as I can tell by now, this fixes the problem at hand. Any ideas if this is a safe fix? > > Joachim > > > Am 01.07.15 um 12:35 schrieb jtuchel(a)objektfabrik.de: >> Hi there, >> >> I am on VA Smalltalk and therefor using an older version of NeoCSV (SvenVanCaekenberghe.14). I found a bug in this old version that is somewhat special. >> >> It seems NeoCSV cannot handle the situation where the very last field is just empty AND if there is no trailing CRLF at the end of the file. Somethinng like this: >> >> SecondLastColumnValue;;<EOF> >> >> In that case, readField fails because it tries to do a readQuotedField or readUnquotedField, both of which try to read beyond EOF. >> >> So I changed readField to this: >> >> readField >> >> ^self atEnd "In case the very last field of a file is empty, like '45;56;;'" >> ifTrue: [''] >> ifFalse: [self peekQuote ifTrue: [self readQuotedField] ifFalse: [self readUnquotedField]] >> >> and all seems fine so far. >> >> Side note: My original file has a trailing CrLf but if I upload it via a browser to a Seaside Server, the Browser cuts off the trailing CrLf (I can see this in the Browser's Network debugging tools - both in IE and FF) - so it seems NeoCSV has to be ready for this situation. >> >> Joachim >> >> > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >

July 1, 2015

Re: [Pharo-users] NeoCSVReader and an empty field at the very end of a file

by jtuchel＠objektfabrik.de

Hi, I've tried porting SvenVanCaekenberghe.20 and see the same problems in this version. IN addition to the fix already mentioned, I also had to change readSeparator: readSeparator ^self atEnd ifFalse: [self peekFor: separator] As far as I can tell by now, this fixes the problem at hand. Any ideas if this is a safe fix? Joachim Am 01.07.15 um 12:35 schrieb jtuchel(a)objektfabrik.de: > Hi there, > > I am on VA Smalltalk and therefor using an older version of NeoCSV > (SvenVanCaekenberghe.14). I found a bug in this old version that is > somewhat special. > > It seems NeoCSV cannot handle the situation where the very last field > is just empty AND if there is no trailing CRLF at the end of the file. > Somethinng like this: > > SecondLastColumnValue;;<EOF> > > In that case, readField fails because it tries to do a readQuotedField > or readUnquotedField, both of which try to read beyond EOF. > > So I changed readField to this: > > readField > > ^self atEnd "In case the very last field of a file is empty, like > '45;56;;'" > ifTrue: [''] > ifFalse: [self peekQuote ifTrue: [self readQuotedField] > ifFalse: [self readUnquotedField]] > > and all seems fine so far. > > Side note: My original file has a trailing CrLf but if I upload it via > a browser to a Seaside Server, the Browser cuts off the trailing CrLf > (I can see this in the Browser's Network debugging tools - both in IE > and FF) - so it seems NeoCSV has to be ready for this situation. > > Joachim > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

July 1, 2015

Re: [Pharo-users] [Ann] DragPanels: Floating palette windows with drag-and-drop in Morphic

by H. Hirzel

Thank you for the custom made class CardsSvgWriter I loaded it from http://smalltalkhub.com/#!/~StephanEggermont/Documentation CardsMorphic-StephanEggermont.57 through the Monticello Browser. BTW Gofer new smalltalkhubUser: 'StephanEggermont' project: 'Documentation' package: 'CardsMorphic'; load. taken from above gives an error message. I understand that there is no menu command yet to do the export so I did CardsSvgWriter newFile: 'cards.svg' on: (CardWall allInstances at: 1) in a playground workspace window. I suggest to include that the context menu. Texts are preserved in the svg file, so search is possible. Fontsize is an issue: in the exported SVG file it is much smaller than in the CardWall panel. Adding a card by just typing the card text and hitting '<ENTER>' would be nice. --Hannes On 6/30/15, Stephan Eggermont <stephan(a)stack.nl> wrote: > The export as SVG is indeed easy. > I've added this helper class to CardsMorphic-StephanEggermont.56 > It is not well-factored, and for now ignores font families. > > A class helper method to directly create a file: > > CardSvgWriter class>newFile: aString on: aCardWall > ^self new write: aCardWall to: (aString asFileReference writeStream ) > > Write a SVG header, the size and then the contents of the cardwall, > finally close the SVG. > > CardSvgWriter>>write: aWall to: aStream > stream := aStream. > stream nextPutAll: self fileHeader. > self fileSized: aWall fullFrame. > stream cr. > aWall cardSpace submorphsDo: [ :column | > self writeColumn: column]. > stream nextPutAll: '</svg>'. > stream close > > SVG is an XML format > > CardSvgWriter>>fileHeader > ^'<?xml version="1.0" standalone="no"?> > <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" > "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> > ' > > Take the SVG size from the CardWall morph. Two namespaces are needed, > the second one to make the images work. > > CardSvgWriter>>fileSized: frame > stream nextPutAll: '<svg xmlns="http://www.w3.org/2000/svg" > xmlns:xlink="http://www.w3.org/1999/xlink" viewBox = "', > (frame left) asString,' ', > (frame top) asString,' ', > (frame width) asString,' ', > (frame height) asString,'" version = "1.1">' > > For each column, write the title and a gray background > > CardSvgWriter>>writeColumn: aColumn > |background| > stream nextPutAll: '<text x="',(aColumn left+2) asString,'" > y="',(aColumn top+2) asString,'" fill="gray" font-size= "11">'. > stream nextPutAll: aColumn title. > stream nextPutAll: '</text>'. > stream cr. > background := aColumn submorphs first. > stream nextPutAll: '<rect x= "',(background left) asString, > '" y="',(background top) asString, > '" width="',(background width) asString, > '" height="',(background height) asString, > '" fill="rgb(250,250,250)" />'. > stream cr. > background submorphsDo: [ :card | self writeCard: card ]. > > for each card, write its components > > CardSvgWriter>>writeCard: aCard > self writeCardRectangle: aCard. > self writeCardText: aCard. > self writeCardImage: aCard > > The rectangle still has hardcoded border and borderColor > > CardSvgWriter>>writeCardRectangle: aCard > stream nextPutAll: '<rect x= "',(aCard left) asString, > '" y="',(aCard top) asString, > '" width="',(aCard width) asString, > '" height="',(aCard height) asString, > '" stroke="','rgb(240,240,240)'"aCard borderColor asHTMLColor", > '" stroke-width="', '1',"aCard borderWidth asString," > '" fill="',aCard color asHTMLColor,'" />'. > stream cr. > > Positioning of text is different in SVG and Morphic. In SVG, > it is the left-bottom, vs left-top in Morphic. > > CardSVGWriter>>writeCardText: aCard > stream nextPutAll: '<text x="',(aCard left+2) asString,'" y="',(aCard > top+12) asString,'" fill="black" font-size= "10">'. > stream nextPutAll: aCard title. > stream nextPutAll: '</text>'. > stream cr. > > The avatars are jpegs. they need to be base64 encoded. > Here they are repeated for each card, they should be > written once and linked. > > CardSVGWriter>writeCardImage: aCard > aCard person ifNotNil: [ > stream nextPutAll: '<image x="',(aCard right-32) asString,'" > y="',(aCard bottom-32) asString,'" width="32" height="32" > xlink:href="data:image/jpg;base64,', > (ZnUtils encodeBase64: (ByteArray streamContents: [:s | > PluginBasedJPEGReadWriter putForm: (AvatarCache default imageFor: > aCard person) onStream: s])) > ,'"/>'. > stream cr] > >

July 1, 2015

Re: [Pharo-users] pharo looses font settings on linux with retina screen

by Martin BÃ¤hr

Excerpts from Esteban Lorenzano's message of 2015-07-01 11:56:21 +0200: > currently fonts+retina display is not a good combination :( > > can you link a screenshot of the problem you are describing? http://societyserver.org/scripts/get.pike?object=137514 i just ran into another issue. when i inspect that "IndexInterface open." in the playground, the fontsize resets right there. greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

July 1, 2015

NeoCSVReader and an empty field at the very end of a file

by jtuchel＠objektfabrik.de

Hi there, I am on VA Smalltalk and therefor using an older version of NeoCSV (SvenVanCaekenberghe.14). I found a bug in this old version that is somewhat special. It seems NeoCSV cannot handle the situation where the very last field is just empty AND if there is no trailing CRLF at the end of the file. Somethinng like this: SecondLastColumnValue;;<EOF> In that case, readField fails because it tries to do a readQuotedField or readUnquotedField, both of which try to read beyond EOF. So I changed readField to this: readField ^self atEnd "In case the very last field of a file is empty, like '45;56;;'" ifTrue: [''] ifFalse: [self peekQuote ifTrue: [self readQuotedField] ifFalse: [self readUnquotedField]] and all seems fine so far. Side note: My original file has a trailing CrLf but if I upload it via a browser to a Seaside Server, the Browser cuts off the trailing CrLf (I can see this in the Browser's Network debugging tools - both in IE and FF) - so it seems NeoCSV has to be ready for this situation. Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

July 1, 2015

Re: [Pharo-users] pharo looses font settings on linux with retina screen

by Esteban Lorenzano

currently fonts+retina display is not a good combination :( can you link a screenshot of the problem you are describing? Esteban > On 01 Jul 2015, at 11:47, Martin BÃ¤hr <mbaehr(a)email.archlab.tuwien.ac.at> wrote: > > hi, > > i am running pharo 40614 on linux on a mac with a retina screen. > > i have not tested this on a normal laptop yet, so i don't know if the retina > resolution is the problem or the pharo version i am using. probably a bit of both. > > the worst issue is that when i restart an image, the font settings are > partially lost and reverted to the original size, which is to small to read on > such a screen. and restoring the font size requires me to reopen all the affected windows. > > there are also issues with some widgets not resizing to the full size of the > font, making the text only partially readable. > > and then there are widgets that have the correct size, but the font remains small. > > and all that is not consistent, sometimes all sizes are correct, sometimes it > is a complete mess. pretty much every time i restart after resetting the font > size i get different results. it makes pharo practically unusable on this > machine, because i am spending to much time fixing fonts, and am not getting > any work done. > > is there some other setting to adjust to the resolution besides selecting a huge font? > > greetings, martin. > > -- > eKita - the online platform for your entire academic life > -- > chief engineer eKita.co > pike programmer pike.lysator.liu.se caudium.net societyserver.org > secretary beijinglug.org > mentor fossasia.org > foresight developer foresightlinux.org realss.com > unix sysadmin > Martin BÃ¤hr working in china http://societyserver.org/mbaehr/ >

July 1, 2015

pharo looses font settings on linux with retina screen

by Martin BÃ¤hr

hi, i am running pharo 40614 on linux on a mac with a retina screen. i have not tested this on a normal laptop yet, so i don't know if the retina resolution is the problem or the pharo version i am using. probably a bit of both. the worst issue is that when i restart an image, the font settings are partially lost and reverted to the original size, which is to small to read on such a screen. and restoring the font size requires me to reopen all the affected windows. there are also issues with some widgets not resizing to the full size of the font, making the text only partially readable. and then there are widgets that have the correct size, but the font remains small. and all that is not consistent, sometimes all sizes are correct, sometimes it is a complete mess. pretty much every time i restart after resetting the font size i get different results. it makes pharo practically unusable on this machine, because i am spending to much time fixing fonts, and am not getting any work done. is there some other setting to adjust to the resolution besides selecting a huge font? greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

July 1, 2015

Re: [Pharo-users] does anybody use the AST navigation?

by Marcus Denker

> On 30 Jun 2015, at 19:21, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > does any of you use the AST code navigation? > Because we could remove it. I think we never enabled it because we could not use good key combinationsâ¦ the idea was to use ctrl-arrow keys for itâ¦ I still think that AST based navigation is a very good idea, removing it now without having ever used it for real is not good. Marcus

July 1, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by Jan BlizniÄenko

I tried commenting primFlush: fileID in StandardFileStream>>#flush on my desktop PC and the "store" benchmark's speed improved significantly. Original result on Windows 7: 11 per sec Result without flushing on Windows 7: 9 430 per sec Original result on Linux Mint 17: 26 590 per sec Result without flushing on Linux Mint 17: 34 879 per sec Mentioned Linux Mint is in VirtualBox on the same PC. Also loading of Roassal2 now takes 58 seconds insted of 386. Jan Nicolai Hess wrote > 2015-07-01 7:46 GMT+02:00 Jan BlizniÄenko < > bliznjan@.cvut > >: > >> Sounds good, could I try it and run all those benchmarks etc. on it on my >> PCs? >> >> Jan >> > > With this: > http://stackoverflow.com/questions/14290337/is-fwrite-faster-than-writefile… > It seems this all comes down to calling FlushFileBuffers. > > You can check what would happen if we just disabling the explicit flushing > (comment out > self primFlush: fileID > in StandardFileStream>>#flush) > and run the benchmarks. > > > (Of course, I don't know what side effects this have, *I* think WriteFile > calls flush on > its own, and of course *if* this solves the problem, we can not just > disable call to flush in the > image, but have to change the windows file plugin). > > > > > > >> >> >> Nicolai Hess wrote >> > Yes, the vm primitives, like I already told some messages above. >> > FilePrimitives ARE slow on windows. >> > >> > We may get better performance, if we disable windows file >> cache/buffering >> > and use slightly different ways to do the CreateFile and WriteFile >> > calls, and do the buffering on our own, but this is not easy. >> > >> > Luckily (?), this may be alread work if we use the std file api (?) >> > >> > A small dirty test: >> > >> > store bench >> > latest vm -> '22.098 per second' >> > modified vm -> '31,027 per second' >> > >> > (in the modified vm I replaced all file operation from >> > sqWin32FilePrims.c >> > with the code from >> > sqFilePluginBasicPrims.c) >> > >> > The result may seem strange, because both implementation will actually >> use >> > win32s CreateFile/WriteFile methods, but >> > maybe the second one uses better caching/buffering. >> > >> > nicolai >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> -- View this message in context: http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 1, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by Nicolai Hess

2015-07-01 7:46 GMT+02:00 Jan BlizniÄenko <bliznjan(a)fit.cvut.cz>: > Sounds good, could I try it and run all those benchmarks etc. on it on my > PCs? > > Jan > With this: http://stackoverflow.com/questions/14290337/is-fwrite-faster-than-writefile… It seems this all comes down to calling FlushFileBuffers. You can check what would happen if we just disabling the explicit flushing (comment out self primFlush: fileID in StandardFileStream>>#flush) and run the benchmarks. (Of course, I don't know what side effects this have, *I* think WriteFile calls flush on its own, and of course *if* this solves the problem, we can not just disable call to flush in the image, but have to change the windows file plugin). > > > Nicolai Hess wrote > > Yes, the vm primitives, like I already told some messages above. > > FilePrimitives ARE slow on windows. > > > > We may get better performance, if we disable windows file cache/buffering > > and use slightly different ways to do the CreateFile and WriteFile > > calls, and do the buffering on our own, but this is not easy. > > > > Luckily (?), this may be alread work if we use the std file api (?) > > > > A small dirty test: > > > > store bench > > latest vm -> '22.098 per second' > > modified vm -> '31,027 per second' > > > > (in the modified vm I replaced all file operation from > > sqWin32FilePrims.c > > with the code from > > sqFilePluginBasicPrims.c) > > > > The result may seem strange, because both implementation will actually > use > > win32s CreateFile/WriteFile methods, but > > maybe the second one uses better caching/buffering. > > > > nicolai > > > > > > -- > View this message in context: > http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

July 1, 2015