- Pharo-users - lists.pharo.org

Re: [Pharo-users] 'function unavailable' when calling OpenDBXDriver for MySQL

by Markus Fritsche

Hello Brad, On 2014-11-17 17:34, bsselfridge(a)gmail.com wrote: > My database is 64 bit on my 64bit Ubuntu machine. > > However, on my 32bit Ubuntu 14.04 machine, I have a 64 debian VM > running > that has a 64bit MySQL running which I can access just fine from 32bit > host > machine running Pharo. I would guess that the 32 Bit MySQL client libraries are not installed. Please check if you have libmysqlclient:i386 and libopendbx:i386 (or what the proper name is, I'm not on an ubuntu machine right now) installed. dpkg -l | grep mysql | awk ' { print $2 } ' dpkg -l | grep dbx | awk ' { print $2 } '

Nov. 17, 2014

Re: [Pharo-users] 'function unavailable' when calling OpenDBXDriver for MySQL

by bsselfridge＠gmail.com

My database is 64 bit on my 64bit Ubuntu machine. However, on my 32bit Ubuntu 14.04 machine, I have a 64 debian VM running that has a 64bit MySQL running which I can access just fine from 32bit host machine running Pharo. ----- Brad Selfridge -- View this message in context: http://forum.world.st/function-unavailable-when-calling-OpenDBXDriver-for-M… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 17, 2014

Re: [Pharo-users] 'function unavailable' when calling OpenDBXDriver for MySQL

by Stephan Eggermont

Hi Brad, You don't tell us if your MySQL is 32 bit? Stephan

Nov. 17, 2014

Re: [Pharo-users] 'function unavailable' when calling OpenDBXDriver for MySQL

by bsselfridge＠gmail.com

Ill have to check Brad Selfridge 913-269-2385 > On Nov 17, 2014, at 9:41 AM, Stephan Eggermont [via Smalltalk] <ml-node+s1294792n4790646h20(a)n4.nabble.com> wrote: > > Hi Brad, > > You don't tell us if your MySQL is 32 bit? > > Stephan > > > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/function-unavailable-when-calling-OpenDBXDriver-for-M… > To unsubscribe from 'function unavailable' when calling OpenDBXDriver for MySQL, click here. > NAML ----- Brad Selfridge -- View this message in context: http://forum.world.st/function-unavailable-when-calling-OpenDBXDriver-for-M… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 17, 2014

Re: [Pharo-users] 'function unavailable' when calling OpenDBXDriver for MySQL

by bsselfridge＠gmail.com

It looks like eveything is there. This configuration looks almost identical to my 32os machine. root@brads-linux-laptop:/usr/lib# ldd libopendbx.so.1.2.0 linux-gate.so.1 => (0xf76df000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf76b8000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7508000) /lib/ld-linux.so.2 (0xf76e0000) root@brads-linux-laptop:/usr/lib# ----- Brad Selfridge -- View this message in context: http://forum.world.st/function-unavailable-when-calling-OpenDBXDriver-for-M… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 17, 2014

Re: [Pharo-users] MultiByteFileStream problem

by JosÃ© ComesaÃ±a

Thank you for the idea Phil, but I'd like the same code to work both on OSX and Windows. I don't like calling OS commands, either (my fault, I know...) 2014-11-17 11:30 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > I do not know which OS you are on. > > But I have solved a similar problem by calling tail -5 through OSProcess > on Linux for a quick fix. > > tac file can also help to read a file in reverse. > > Phil > > On Mon, Nov 17, 2014 at 10:20 AM, JosÃ© ComesaÃ±a <jose.comesana(a)gmail.com> > wrote: > >> Thank you Sven. >> >> I an trying to read a veeeery long log file, and extract the last 5 >> messages for the user to see them. Reading the whole file from the >> beginning is too expensive. So maybe I could try reading backwards from the >> end using binary mode and look for a lf... I have to think about it a >> little bit, and study your proposal, of course. >> >> >> >> >> >> 2014-11-17 9:26 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >>> Hi JosÃ©, >>> >>> > On 17 Nov 2014, at 02:06, JosÃ© ComesaÃ±a <jose.comesana(a)gmail.com> >>> wrote: >>> > >>> > There is an annoying error in MultiByteFileStream, reading back when >>> you have a unicode character. It is also the cause of some FileOut errors. >>> Your can reproduce it this way: >>> > >>> > testString := 'abcdÃ©'. >>> > filename := 'test.txt'. >>> > filename asFileReference ensureDelete. >>> > filename asFileReference >>> > writeStreamDo: [ :stream | >>> > stream >>> > nextPutAll: testString ]. >>> > >>> > f := 'test.txt' asFileReference readStream. >>> > >>> > f setToEnd. >>> > >>> > f skip: -1. >>> > >>> > f peek. >>> > >>> > >>> > Any ideas how to solve it? Avoiding reading back is not an option ;). >>> Maybe making skip to go back one more byte to check if there is a unicode >>> character around?. >>> > >>> > Thanks a lot. >>> >>> This is a known problem/issue/limitation of MultiByteFileStream and the >>> TextConverters. >>> >>> The more modern/logical ZnCharacterEncoders can do this reliably >>> (provided the underlying stream can itself move backwards and the current >>> position is between whole characters). >>> >>> 'test.txt' asFileReference readStreamDo: [ :in | >>> in binary; setToEnd. >>> ZnUTF8Encoder new backOnStream: in; nextFromStream: in ] >>> >>> IMHO, the ability to move backwards and to play with positions without >>> restrictions on streams only makes sense with in-memory streams, not with >>> file or network streams. It plays badly with buffering too. >>> >>> I know this doesn't solve your issue but I hope it gives you a better >>> idea of the situation. >>> >>> Where exactly do you have this issue ? >>> >>> Sven >>> >>> >>> >> >

Nov. 17, 2014

Re: [Pharo-users] MultiByteFileStream problem

by phil＠highoctane.be

I do not know which OS you are on. But I have solved a similar problem by calling tail -5 through OSProcess on Linux for a quick fix. tac file can also help to read a file in reverse. Phil On Mon, Nov 17, 2014 at 10:20 AM, JosÃ© ComesaÃ±a <jose.comesana(a)gmail.com> wrote: > Thank you Sven. > > I an trying to read a veeeery long log file, and extract the last 5 > messages for the user to see them. Reading the whole file from the > beginning is too expensive. So maybe I could try reading backwards from the > end using binary mode and look for a lf... I have to think about it a > little bit, and study your proposal, of course. > > > > > > 2014-11-17 9:26 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> Hi JosÃ©, >> >> > On 17 Nov 2014, at 02:06, JosÃ© ComesaÃ±a <jose.comesana(a)gmail.com> >> wrote: >> > >> > There is an annoying error in MultiByteFileStream, reading back when >> you have a unicode character. It is also the cause of some FileOut errors. >> Your can reproduce it this way: >> > >> > testString := 'abcdÃ©'. >> > filename := 'test.txt'. >> > filename asFileReference ensureDelete. >> > filename asFileReference >> > writeStreamDo: [ :stream | >> > stream >> > nextPutAll: testString ]. >> > >> > f := 'test.txt' asFileReference readStream. >> > >> > f setToEnd. >> > >> > f skip: -1. >> > >> > f peek. >> > >> > >> > Any ideas how to solve it? Avoiding reading back is not an option ;). >> Maybe making skip to go back one more byte to check if there is a unicode >> character around?. >> > >> > Thanks a lot. >> >> This is a known problem/issue/limitation of MultiByteFileStream and the >> TextConverters. >> >> The more modern/logical ZnCharacterEncoders can do this reliably >> (provided the underlying stream can itself move backwards and the current >> position is between whole characters). >> >> 'test.txt' asFileReference readStreamDo: [ :in | >> in binary; setToEnd. >> ZnUTF8Encoder new backOnStream: in; nextFromStream: in ] >> >> IMHO, the ability to move backwards and to play with positions without >> restrictions on streams only makes sense with in-memory streams, not with >> file or network streams. It plays badly with buffering too. >> >> I know this doesn't solve your issue but I hope it gives you a better >> idea of the situation. >> >> Where exactly do you have this issue ? >> >> Sven >> >> >> >

Nov. 17, 2014

Re: [Pharo-users] Opentalk or remoting libraries

by Norbert Hartl

Using fuel should be way faster than plain textual serialization. A direct copy of memory would be theoretically faster but you would need to manage references anyway so it is not clear what can be gained. Norbert > Am 17.11.2014 um 11:05 schrieb Annick Fron <list(a)afceurope.com>: > > Thank you, > My need is on a local network from machine to machine, in real time is possible, so no security involved. > I would have preferred something more performant than web services or XMLRPC, since both serialization and XML serialization are slow. > Annick > Le 13 nov. 2014 Ã 20:17, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > >> Nice. >> >> It is of course also important to note the security risks involved: the client can execute absolutely anything. >> >> One partial solution is to bind the server only to the localhost. >> >>> On 13 Nov 2014, at 19:17, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: >>> >>> Hi, >>> CORBA main focus is about interoperability between systems, languages (don't know about opentalk). >>> If you want smalltalk only remote execution, you can very easily do your own on Pharo with Zinc http components and Fuel serializer: a small server that reads smalltalk blocks, evaluates them and return the result (see below an example of server and client). >>> I don't know if Zinc and Fuel run on Squeak, but I guess if not, they are equivalents ones or you could do the same. >>> Beware that Fuel builds a graph of the objects touched by the object it serializes (the block) and serialize them along the way, that may be a problem if you have references to other big objects of your image. >>> >>> " ================================= RPC server" >>> " start Zn server in background " >>> ZnServer startDefaultOn: 1701. >>> ZnServer default delegate: (ZnWebSocketDelegate handler: >>> ([ :webSocket | >>> [ [ | serializedRequest request response serializedResponse | >>> serializedRequest := webSocket readMessage. >>> request := FLMaterializer materializeFromByteArray: serializedRequest. >>> "execute block and it's value to response byte array" >>> response := [ request value ] >>> on: Exception do: [ :ex | ex resume: 'Exception ',ex class name , ' - ', ex messageText ]. >>> serializedResponse := FLSerializer serializeToByteArray: response . >>> webSocket sendMessage: serializedResponse . >>> ] repeat. >>> ] >>> on: ConnectionClosed, ConnectionTimedOut >>> do: [ self crLog: 'Ignoring connection or timeout' ] >>> ]) ). >>> "=========================================" >>> >>> " to stop the server" >>> ZnServer stopDefault . >>> >>> >>> >>> "========================================= RPC CLIENT" >>> >>> " Client call to server: calculate factorial 100 on the other side" >>> | webSocket | >>> webSocket := ZnWebSocket to: 'ws://127.0.0.1:1701'. >>> [ | request serializedRequest serializedResponse response | >>> request := [ 100 factorial ] . " the request is the block to evaluate" >>> serializedRequest := FLSerializer serializeToByteArray: request . "serialize the block" >>> webSocket sendMessage: serializedRequest . "send it" >>> serializedResponse := webSocket readMessage . " read response" >>> response := FLMaterializer materializeFromByteArray: serializedResponse. "deserialize to object" >>> Transcript show: response asString ; cr ] >>> on: ConnectionClosed >>> do: [ self crLog: 'Ignoring connection close, done' ] >>> >>> >>> regards, >>> >>> Alain >>> >>> >>> Le 12/11/2014 18:17, Annick Fron a Ã©crit : >>>> Hi, >>>> >>>> Are there some libraries in pharo to do remote calls like in Opentalk or Corba ? >>>> >>>> Annick >>>> >>> >>> >>> >> >> > >

Nov. 17, 2014

Re: [Pharo-users] Opentalk or remoting libraries

by Annick Fron

Thank you, My need is on a local network from machine to machine, in real time is possible, so no security involved. I would have preferred something more performant than web services or XMLRPC, since both serialization and XML serialization are slow. Annick Le 13 nov. 2014 Ã 20:17, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > Nice. > > It is of course also important to note the security risks involved: the client can execute absolutely anything. > > One partial solution is to bind the server only to the localhost. > >> On 13 Nov 2014, at 19:17, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: >> >> Hi, >> CORBA main focus is about interoperability between systems, languages (don't know about opentalk). >> If you want smalltalk only remote execution, you can very easily do your own on Pharo with Zinc http components and Fuel serializer: a small server that reads smalltalk blocks, evaluates them and return the result (see below an example of server and client). >> I don't know if Zinc and Fuel run on Squeak, but I guess if not, they are equivalents ones or you could do the same. >> Beware that Fuel builds a graph of the objects touched by the object it serializes (the block) and serialize them along the way, that may be a problem if you have references to other big objects of your image. >> >> " ================================= RPC server" >> " start Zn server in background " >> ZnServer startDefaultOn: 1701. >> ZnServer default delegate: (ZnWebSocketDelegate handler: >> ([ :webSocket | >> [ [ | serializedRequest request response serializedResponse | >> serializedRequest := webSocket readMessage. >> request := FLMaterializer materializeFromByteArray: serializedRequest. >> "execute block and it's value to response byte array" >> response := [ request value ] >> on: Exception do: [ :ex | ex resume: 'Exception ',ex class name , ' - ', ex messageText ]. >> serializedResponse := FLSerializer serializeToByteArray: response . >> webSocket sendMessage: serializedResponse . >> ] repeat. >> ] >> on: ConnectionClosed, ConnectionTimedOut >> do: [ self crLog: 'Ignoring connection or timeout' ] >> ]) ). >> "=========================================" >> >> " to stop the server" >> ZnServer stopDefault . >> >> >> >> "========================================= RPC CLIENT" >> >> " Client call to server: calculate factorial 100 on the other side" >> | webSocket | >> webSocket := ZnWebSocket to: 'ws://127.0.0.1:1701'. >> [ | request serializedRequest serializedResponse response | >> request := [ 100 factorial ] . " the request is the block to evaluate" >> serializedRequest := FLSerializer serializeToByteArray: request . "serialize the block" >> webSocket sendMessage: serializedRequest . "send it" >> serializedResponse := webSocket readMessage . " read response" >> response := FLMaterializer materializeFromByteArray: serializedResponse. "deserialize to object" >> Transcript show: response asString ; cr ] >> on: ConnectionClosed >> do: [ self crLog: 'Ignoring connection close, done' ] >> >> >> regards, >> >> Alain >> >> >> Le 12/11/2014 18:17, Annick Fron a Ã©crit : >>> Hi, >>> >>> Are there some libraries in pharo to do remote calls like in Opentalk or Corba ? >>> >>> Annick >>> >> >> >> > >

Nov. 17, 2014

Re: [Pharo-users] running out of memory while processing a 220MB csv file with NeoCSVReader - tips?

by Stephan Eggermont

Open package contents on your vm, open Contents, take a look at the info.plist <key>SqueakMaxHeapSize</key> <integer>541065216</integer> That value needs to be increased to be able to use more than ~512 MB. Alain wrote: >Let say it's your current requirement, and you want to do it like that, >a trick that may help you : during personal experiments about loading >data in memory and statistics from databases, I found that most often 70 >to 80 % of real data is the same. It is easy to confirm if this is the case in your data: just zip the csv file. Reasonably structured relational database output often reduces to 10% of size. With explicitly denormalized data I've seen 99% reduction. In addition, DateAndTime has a rather wasteful representation for your purpose. Just reduce to one SmallInt, or with Pharo4, use slots to get a more compact record representation. Stephan

Nov. 17, 2014