[GEM-dev] pix_share_write error

[Antoine Villeret]

2013/3/19 IOhannes m zmoelnig <zmoelnig at iem.at>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2013-03-19 16:06, Antoine Villeret wrote:
> > this is in my github repos in the branch pix_share_write :
> > https://github.com/avilleret/Gem/tree/pix_share_write
>
> hehe, i have incorporated your changes about 7 hours ago :-)
>

thanks for that

>
> >
> > I don't know if it's a good idea but it seems to work for me
>
> generally, i find it always pleasing, if an error is not (only)
> printed to the pd-console but you get some message back into the
> patch, so you can react on the error programmatically.
>
> > I'm wondering if it could be good to have a dictionary instead of a
> > hash table : when we use [set id sizex sizey pixel_format( message,
> > pix_share* could try to find the id in the dictionary if there is
> > no entry with that id, it generates a random shmem id, verify that
> > nobody else is using it and tries to allocated data if it fails it
> > could generates another id until it succeed and store the id in the
> > dictionary
> >
> > pix_share_read will know the dictionary and can find the right
> > shmem id
>
> how is that supposed to work in two separate instances of Pd?
>

obviously, i forgot that whereas I'm sending id though OSC to other
instance...
and I see no other ways than sending the id on localhost...

sorry for this stupid mistake

cheers

a

>
> fgamsdr
> IOhannes
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlFIiw8ACgkQkX2Xpv6ydvQxGgCePjlJJTseMuPVMhuYQGWkavgv
> u10AoMhpJaE6OsdPQk7HbhmMM0W75aTo
> =5+nU
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20130319/cf57c652/attachment.htm>