January 2024 - Pharo-users - lists.pharo.org

Re: Troubleshooting ByteArray

by Todd Blanchard

Try this: (PDFDocument new compression: false)add: (PDFPage new add: (PDFTextElement new text: 'Hello'; from: 10mm@10mm)); exportTo: 'test.pdf' asFileReference writeStream. Compression causes your string to be gzipâd which is a ByteArray and not a String of any kind. Unfortunately, the write stream is a ZnCharacterWriteStream which is expecting some kind of String. This is going to take some untangling so just turn off compression (which is on by default) and it seems to work. > On Jan 17, 2024, at 4:43â¯PM, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > So the method is expecting some kind of string, but it received a > ByteArray, which is NOT any kind of string. > What's in the ByteArray? Where did it come from? Why isn't it a string? > > On Thu, 18 Jan 2024 at 04:34, sergio ruiz <sergio.rrd(a)gmail.com> wrote: >> >> Hi, all. >> >> I am working on creating a PDF with Artefact (https://github.com/pharo-contributions/Artefact) and am having an issue running the first example. >> >> the Example looks like: >> >> PDFDocument new add: (PDFPage new add: (PDFTextElement new text: 'Hello'; from: 10mm@10mm)); exportTo: 'test.pdf' asFileReference writeStream. >> >> >> When running this, I get the error: >> >> Instance of ByteArray did not understand #isByteString >> >> indeed, ByteArray does not have a method called isByteString. >> >> I have tried creating a method that returns either true or false (I tried them both), but I have not successfully built the PDF. >> >> The method calling isByteString looks like: >> >> >> ZnUTF8Encoder >> >> next: count putAll: string startingAt: offset toStream: stream >> "Write count characters from string starting at offset to stream." >> "Overwritten for performance reasons - create a fast path for byte strings" >> >> string isByteString >> ifTrue: [ self next: count putAllByteString: string startingAt: offset toStream: stream ] >> ifFalse: [ super next: count putAll: string startingAt: offset toStream: stream ] >> >> I TOTALLY get this. This is a whole bunch of very specific questions. But my ultimate goal is to take a deep dive into stream processing to figure this out. >> >> Thanks! >> >> ---- >> peace, >> sergio >> photographer, journalist, visionary >> >> Public Key: https://pgp.key-server.io/pks/lookup?op=get&search=0x69B08F58923AB3A2 >> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV >> @sergio_101@mastodon.social >> https://sergio101.com >> http://www.codeandmusic.com >> http://www.twitter.com/sergio_101 >> http://www.facebook.com/sergio101 >>

Jan. 18, 2024

Re: Troubleshooting ByteArray

by Richard O'Keefe

So the method is expecting some kind of string, but it received a ByteArray, which is NOT any kind of string. What's in the ByteArray? Where did it come from? Why isn't it a string? On Thu, 18 Jan 2024 at 04:34, sergio ruiz <sergio.rrd(a)gmail.com> wrote: > > Hi, all. > > I am working on creating a PDF with Artefact (https://github.com/pharo-contributions/Artefact) and am having an issue running the first example. > > the Example looks like: > > PDFDocument new add: (PDFPage new add: (PDFTextElement new text: 'Hello'; from: 10mm@10mm)); exportTo: 'test.pdf' asFileReference writeStream. > > > When running this, I get the error: > > Instance of ByteArray did not understand #isByteString > > indeed, ByteArray does not have a method called isByteString. > > I have tried creating a method that returns either true or false (I tried them both), but I have not successfully built the PDF. > > The method calling isByteString looks like: > > > ZnUTF8Encoder > > next: count putAll: string startingAt: offset toStream: stream > "Write count characters from string starting at offset to stream." > "Overwritten for performance reasons - create a fast path for byte strings" > > string isByteString > ifTrue: [ self next: count putAllByteString: string startingAt: offset toStream: stream ] > ifFalse: [ super next: count putAll: string startingAt: offset toStream: stream ] > > I TOTALLY get this. This is a whole bunch of very specific questions. But my ultimate goal is to take a deep dive into stream processing to figure this out. > > Thanks! > > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: https://pgp.key-server.io/pks/lookup?op=get&search=0x69B08F58923AB3A2 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > @sergio_101@mastodon.social > https://sergio101.com > http://www.codeandmusic.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 >

Jan. 17, 2024

Troubleshooting ByteArray

by sergio ruiz

Hi, all. I am working on creating a PDF with Artefact (https://github.com/pharo-contributions/Artefact) and am having an issue running the first example. the Example looks like: PDFDocument new add: (PDFPage new add: (PDFTextElement new text: 'Hello'; from: 10mm@10mm)); exportTo: 'test.pdf' asFileReference writeStream. When running this, I get the error: Instance of ByteArray did not understand #isByteString indeed, ByteArray does not have a method called isByteString. I have tried creating a method that returns either true or false (I tried them both), but I have not successfully built the PDF. The method calling isByteString looks like: ZnUTF8Encoder next: count putAll: string startingAt: offset toStream: stream "Write count characters from string starting at offset to stream." "Overwritten for performance reasons - create a fast path for byte strings" string isByteString ifTrue: [ self next: count putAllByteString: string startingAt: offset toStream: stream ] ifFalse: [ super next: count putAll: string startingAt: offset toStream: stream ] I TOTALLY get this. This is a whole bunch of very specific questions. But my ultimate goal is to take a deep dive into stream processing to figure this out. Thanks! ---- peace, sergio photographer, journalist, visionary Public Key: https://pgp.key-server.io/pks/lookup?op=get&search=0x69B08F58923AB3A2 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV @sergio_101@mastodon.social https://sergio101.com http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

Jan. 17, 2024

Re: [ Security ] Accessing private information from Pharo image

by James Foster

On Jan 17, 2024, at 3:55â¯AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > the example is about cloud servers. So we can rule out thumb drives easily ;) â¦ > > Norbert I read the following to say that the goal is to talk to a cloud server from a non-cloud client. > One of my projects logs in to Spaces (Digital Oceanâs version of S3). James

Jan. 17, 2024

Re: [ Security ] Accessing private information from Pharo image

by Norbert Hartl

> Am 17.01.2024 um 13:50 schrieb Noury Bouraqadi <bouraqadi(a)gmail.com>: > > Many cloud platforms provide a secrets manager. It sets up env variables with secrets you need. > This is technically a good idea but legally probably bad. If you hand out cleartext credentials to your cloud provider you add that provider to the security chain. Would be interesting to read the terms & conditions for that. ;) Or there is something really clever going on. Do you have any pointers? thanks, Norbert > Noury > > On Jan 17 2024, at 12:55 pm, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 17.01.2024 um 12:31 schrieb Richard O'Keefe <raoknz(a)gmail.com>: > > > > Back in the days when an entire department would share something like > > a VAX and think themselves > > lucky, the advance was never to let secrets *rest* in your address > > space any longer than you had to. > > Bring the secret into memory just the instant before you need it, use > > it, then scrub that area of > > memory. You might want to put the credentials on a thumb drive which > > is plugged in only when needed, > > the example is about cloud servers. So we can rule out thumb drives easily ;) Scrubbing memory is only useful if you donât need access at random which the examples sounds like. > > > I've generally found it better for environment variables to contain > > file names pointing to configuration > > files than to have then hold the configuration information directly. > > If you use files you have just one more thing where you can screw up things like file permissions. And the question is where does the file come from? Especially if you use something like docker with ephemeral containers. > > Norbert > > > > > On Wed, 17 Jan 2024 at 22:31, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > >> > >> > >>> Am 17.01.2024 um 05:27 schrieb sergio ruiz <sergio.rrd(a)gmail.com>: > >>> > >>> Hi, all. > >>> > >>> One of my projects logs in to Spaces (Digital Oceanâs version of S3). I need to be able access the credentials, but I donât want to store them in the source code, as I will be using Github to store the projects. > >>> > >>> Is there an accepted way to do this (encryption)? > >>> > >>> Should I store them on the system as environment variables? is this efficient? > >> > >> One of the usualy ways especially on unix systems is to hand credentials in via the process environment. If you execute > >> > >> OSEnvironment current at: âSHELL' > >> > >> in a playground you should see somthing like â/bin/bashâ. So when starting the process you just need to specify the environment variables so that pharo can access it. If you use docker there is a way to specify that easily. > >> > >> Norbert

Jan. 17, 2024

Re: [ Security ] Accessing private information from Pharo image

by Noury Bouraqadi

Many cloud platforms provide a secrets manager. It sets up env variables with secrets you need. Noury On Jan 17 2024, at 12:55 pm, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 17.01.2024 um 12:31 schrieb Richard O'Keefe <raoknz(a)gmail.com>: > > > > Back in the days when an entire department would share something like > > a VAX and think themselves > > lucky, the advance was never to let secrets *rest* in your address > > space any longer than you had to. > > Bring the secret into memory just the instant before you need it, use > > it, then scrub that area of > > memory. You might want to put the credentials on a thumb drive which > > is plugged in only when needed, > > the example is about cloud servers. So we can rule out thumb drives easily ;) Scrubbing memory is only useful if you donât need access at random which the examples sounds like. > > I've generally found it better for environment variables to contain > > file names pointing to configuration > > files than to have then hold the configuration information directly. > > If you use files you have just one more thing where you can screw up things like file permissions. And the question is where does the file come from? Especially if you use something like docker with ephemeral containers. > Norbert > > > > On Wed, 17 Jan 2024 at 22:31, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > >> > >> > >>> Am 17.01.2024 um 05:27 schrieb sergio ruiz <sergio.rrd(a)gmail.com>: > >>> > >>> Hi, all. > >>> > >>> One of my projects logs in to Spaces (Digital Oceanâs version of S3). I need to be able access the credentials, but I donât want to store them in the source code, as I will be using Github to store the projects. > >>> > >>> Is there an accepted way to do this (encryption)? > >>> > >>> Should I store them on the system as environment variables? is this efficient? > >> > >> One of the usualy ways especially on unix systems is to hand credentials in via the process environment. If you execute > >> > >> OSEnvironment current at: âSHELL' > >> > >> in a playground you should see somthing like â/bin/bashâ. So when starting the process you just need to specify the environment variables so that pharo can access it. If you use docker there is a way to specify that easily. > >> > >> Norbert >

Jan. 17, 2024

Re: GLASS Platform - Docker container?

by Gabriel Cotelli

Hi, Besides the links James has sent, there's also https://github.com/ba-st/Docker-GemStone-64/ . It's still a bit in flux because we're not running production code in it yet, but we're using it in our projects for CI ( https://github.com/ba-st-actions/gs64-ci ) and the projects in https://github.com/ba-st are gaining support for GemStone 64 alongside Pharo. Regards, Gabriel On Wed, Jan 17, 2024 at 1:23â¯AM sergio ruiz <sergio.rrd(a)gmail.com> wrote: > > Hi, all. > > I used the GLASS platform years ago, and I was thinking it might be a good > match for my upcoming projects. > > The documentation looks to be the same documentation I used back when I > started with Seaside. > > I am wondering if GLASS has been ported to Docker yet. This seems like a > natural extension. > > Thanks! > > > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: > https://pgp.key-server.io/pks/lookup?op=get&search=0x69B08F58923AB3A2 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > @sergio_101@mastodon.social > https://sergio101.com > http://www.codeandmusic.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 > >

Jan. 17, 2024

Re: [ Security ] Accessing private information from Pharo image

by Norbert Hartl

> Am 17.01.2024 um 12:31 schrieb Richard O'Keefe <raoknz(a)gmail.com>: > > Back in the days when an entire department would share something like > a VAX and think themselves > lucky, the advance was never to let secrets *rest* in your address > space any longer than you had to. > Bring the secret into memory just the instant before you need it, use > it, then scrub that area of > memory. You might want to put the credentials on a thumb drive which > is plugged in only when needed, the example is about cloud servers. So we can rule out thumb drives easily ;) Scrubbing memory is only useful if you donât need access at random which the examples sounds like. > I've generally found it better for environment variables to contain > file names pointing to configuration > files than to have then hold the configuration information directly. If you use files you have just one more thing where you can screw up things like file permissions. And the question is where does the file come from? Especially if you use something like docker with ephemeral containers. Norbert > > On Wed, 17 Jan 2024 at 22:31, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> >>> Am 17.01.2024 um 05:27 schrieb sergio ruiz <sergio.rrd(a)gmail.com>: >>> >>> Hi, all. >>> >>> One of my projects logs in to Spaces (Digital Oceanâs version of S3). I need to be able access the credentials, but I donât want to store them in the source code, as I will be using Github to store the projects. >>> >>> Is there an accepted way to do this (encryption)? >>> >>> Should I store them on the system as environment variables? is this efficient? >> >> One of the usualy ways especially on unix systems is to hand credentials in via the process environment. If you execute >> >> OSEnvironment current at: âSHELL' >> >> in a playground you should see somthing like â/bin/bashâ. So when starting the process you just need to specify the environment variables so that pharo can access it. If you use docker there is a way to specify that easily. >> >> Norbert

Jan. 17, 2024

Re: [ Security ] Accessing private information from Pharo image

by Richard O'Keefe

Back in the days when an entire department would share something like a VAX and think themselves lucky, the advance was never to let secrets *rest* in your address space any longer than you had to. Bring the secret into memory just the instant before you need it, use it, then scrub that area of memory. You might want to put the credentials on a thumb drive which is plugged in only when needed, I've generally found it better for environment variables to contain file names pointing to configuration files than to have then hold the configuration information directly. On Wed, 17 Jan 2024 at 22:31, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > > Am 17.01.2024 um 05:27 schrieb sergio ruiz <sergio.rrd(a)gmail.com>: > > > > Hi, all. > > > > One of my projects logs in to Spaces (Digital Oceanâs version of S3). I need to be able access the credentials, but I donât want to store them in the source code, as I will be using Github to store the projects. > > > > Is there an accepted way to do this (encryption)? > > > > Should I store them on the system as environment variables? is this efficient? > > One of the usualy ways especially on unix systems is to hand credentials in via the process environment. If you execute > > OSEnvironment current at: âSHELL' > > in a playground you should see somthing like â/bin/bashâ. So when starting the process you just need to specify the environment variables so that pharo can access it. If you use docker there is a way to specify that easily. > > Norbert

Jan. 17, 2024

Re: [ Security ] Accessing private information from Pharo image

by Norbert Hartl

> Am 17.01.2024 um 05:27 schrieb sergio ruiz <sergio.rrd(a)gmail.com>: > > Hi, all. > > One of my projects logs in to Spaces (Digital Oceanâs version of S3). I need to be able access the credentials, but I donât want to store them in the source code, as I will be using Github to store the projects. > > Is there an accepted way to do this (encryption)? > > Should I store them on the system as environment variables? is this efficient? One of the usualy ways especially on unix systems is to hand credentials in via the process environment. If you execute OSEnvironment current at: âSHELL' in a playground you should see somthing like â/bin/bashâ. So when starting the process you just need to specify the environment variables so that pharo can access it. If you use docker there is a way to specify that easily. Norbert

Jan. 17, 2024