Re: [PD] check mail with pd ?
On 09/02/14 16:34, Jonathan Wilkes wrote: On 02/08/2014 11:44 PM, Simon Wise wrote: ... It would be nice to be able to do this natively, especially since many Pd programmers are not that familiar with procedural programming. It is certainly practical and worthwhile to extend Pd for this but that requires some of the things that have been long put off till later for a very very long time. Meanwhile the Lua external provides the way to do what remains problematic natively (as much due to policy as anything else) and anyone capable of adding functionality to Pd will find it much much easier to use Lau than to engage in a huge and perhaps fruitless effort to push it into Pd. It sounds like you are rationalizing and encouraging non-development. More pointing out the frustrations that have been experienced in the past, and noting that decisions about what is added to Pd core are very consistent and are very careful, cautious and slow in these areas in particular. As you pointed out adding something like a string type without introducing it to [print] is not good, so ... you use clumsy workarounds that don't actually allow strings in messages, perhaps just pointers to stings with arcane results in [print] ... or write a bunch of replacement core objects that recognise strings to use within the library such as [stringprint] etc ... or use a fork with enhanced types and core objects that may or may not be compatible with some eventual core string type. It may be worth enhancing pd-l2ork this way as it has already departed considerably from pd, their choice has been to speed up development by bypassing these issues and pushing ahead without integration with core Pd, but I think adding strings confined to a small set of string-aware objects which remain otherwise compatible with vanilla the way gridflow added matrices isn't worth it, there is a much greater pay-off with matrices ... gridflow is a huge project with a very substantial library of matrix operations, while the authors long ago abandoned hope of their efforts being included in vanilla and develop in parallel. Development effort on a smaller scale is probably better spent in ways that will integrate with core pd, and there are plenty of those ... including your own solid efforts. But it also sounds like we agree that there is nothing about boxes of text connected with lines that makes string manipulation more difficult than lines of text. Absolutely, just the absence of a well defined string type that can be sent down those lines. Arguments advancing the addition of a string selector to Pd core are very worthwhile, I guess probably on pd-dev? it ultimately is a discussion with Miller. There was a link to something being worked on currently, earlier in this thread. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
On 02/08/2014 11:44 PM, Simon Wise wrote: On 09/02/14 07:59, Jonathan Wilkes wrote: On 02/08/2014 01:40 PM, Martin Peach wrote: A few years ago I implemented a patch for strings in Pd that adds a string or blob type that allows (I think) for what you are describing. I believe it's still part of Pd extended, but Miller didn't like it for some reason. ... I prefer to manipulate strings in a another language as it just seems like a lot of work to make it happen with boxes and wires when you can just call string functions in a high level language. ... Kind of like building a Turing machine holes-in-paper-tape version of a program, it can be an interesting exercise but practically it's useless. Read in transcript of congressional testimony on NSA surveillance. Split into one string for each line. Read one line every second. If a line contains the word "terrorism" make a sound. User takes a drink. Totally useful. :) What is it about boxes connected with lines that you think makes this difficult? Perhaps it is the long term and very well established resistance to adding a few types to the message syntax ... integers capable of indexing reasonable file lengths, strings which don't flood the symbol table, floats that aren't in danger of being truncated, bytes or chars which won't trigger parsing issues. Matrices are available via an external library (gridflow, within its own externals including non-native print and so forth) and GPU video access is possible via GEM with its private message syntax, but core Pd is very focussed on what it originally set out to do. There have been some moves on this, just very slow and careful ones. A graphical dataflow language is very nice for dealing with DSP and with control and interaction logic, and for doing so in a bunch of machines distributed over a network. Pd has lots of good ways to receive and send control messages and link with hardware and other programs. But dataflow and procedural algorithms are quite different and parsing strings is a very common thing to do when programming ... if you are familiar with the procedural way and have a good set of tools available to abstract the details then its easier to just go with what you know. It would be nice to be able to do this natively, especially since many Pd programmers are not that familiar with procedural programming. It is certainly practical and worthwhile to extend Pd for this but that requires some of the things that have been long put off till later for a very very long time. Meanwhile the Lua external provides the way to do what remains problematic natively (as much due to policy as anything else) and anyone capable of adding functionality to Pd will find it much much easier to use Lau than to engage in a huge and perhaps fruitless effort to push it into Pd. It sounds like you are rationalizing and encouraging non-development. But it also sounds like we agree that there is nothing about boxes of text connected with lines that makes string manipulation more difficult than lines of text. -Jonathan Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
On 09/02/14 07:59, Jonathan Wilkes wrote: On 02/08/2014 01:40 PM, Martin Peach wrote: A few years ago I implemented a patch for strings in Pd that adds a string or blob type that allows (I think) for what you are describing. I believe it's still part of Pd extended, but Miller didn't like it for some reason. ... I prefer to manipulate strings in a another language as it just seems like a lot of work to make it happen with boxes and wires when you can just call string functions in a high level language. ... Kind of like building a Turing machine holes-in-paper-tape version of a program, it can be an interesting exercise but practically it's useless. Read in transcript of congressional testimony on NSA surveillance. Split into one string for each line. Read one line every second. If a line contains the word "terrorism" make a sound. User takes a drink. Totally useful. :) What is it about boxes connected with lines that you think makes this difficult? Perhaps it is the long term and very well established resistance to adding a few types to the message syntax ... integers capable of indexing reasonable file lengths, strings which don't flood the symbol table, floats that aren't in danger of being truncated, bytes or chars which won't trigger parsing issues. Matrices are available via an external library (gridflow, within its own externals including non-native print and so forth) and GPU video access is possible via GEM with its private message syntax, but core Pd is very focussed on what it originally set out to do. There have been some moves on this, just very slow and careful ones. A graphical dataflow language is very nice for dealing with DSP and with control and interaction logic, and for doing so in a bunch of machines distributed over a network. Pd has lots of good ways to receive and send control messages and link with hardware and other programs. But dataflow and procedural algorithms are quite different and parsing strings is a very common thing to do when programming ... if you are familiar with the procedural way and have a good set of tools available to abstract the details then its easier to just go with what you know. It would be nice to be able to do this natively, especially since many Pd programmers are not that familiar with procedural programming. It is certainly practical and worthwhile to extend Pd for this but that requires some of the things that have been long put off till later for a very very long time. Meanwhile the Lua external provides the way to do what remains problematic natively (as much due to policy as anything else) and anyone capable of adding functionality to Pd will find it much much easier to use Lau than to engage in a huge and perhaps fruitless effort to push it into Pd. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
thanks frieds for direction. I did a patch . with pyext. and it works ! it does what i want: - check mail box with given subject - count mails with given subject BUT I cant have a trigger (bang) from that. it i strange. Even if my pyext object fills nbx with numbers, it won't give a bang. I think it is a bug. my situation is: [nbx] - with changing number of mails from pyext object (works ok) | | bang -> BUT this bang never works. It is bug. or ? [archinux, pdextended 43.5] -- Fero Kiraly pianist, musician, teacher www.ferokiraly.com www.cluster-ensemble.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
On 02/08/2014 01:40 PM, Martin Peach wrote:
A few years ago I implemented a patch for strings in Pd that adds a
string or blob type that allows (I think) for what you are describing.
I believe it's still part of Pd extended, but Miller didn't like it
for some reason.
It looks more like a prototype for a string implementation. I'm not
even able to do this:
[bng]
|
[str hello_world]
|
[print]
Additionally, moving the cord-inspector over the wire connecting
displays nothing. Those are just the first two things I tried to do as
a user, to view a core atom type which most of the time will be holding
readable text.
It may seem trivial to get those two things to work, but the point is
that someone has to do it, for every single internal and external class
which already understands and can manipulate the one string atom but
doesn't understand the better string atom.
[str hello 32 world] isn't much fun, either. But it's hard to improve
that without the ability for the object box to leave the user input
unparsed.
I prefer to manipulate strings in a another language as it just seems
like a lot of work to make it happen with boxes and wires when you can
just call string functions in a high level language.
I don't understand this. If you take nearly every string manipulation I
did in tcl for the search-plugin and put it in Pd, you are either a)
unrolling several commands in nested square brackets and laying them out
vertically (or inside an abstraction) or b) putting a tcl line of code
in a box and connecting its output to the next line of tcl code in a box
with a wire. If "a" is troublesome to patch and read in Pd then it was
hard to write and read in tcl.
There are of course way more complex examples of string manipulation,
but Pd's tools don't have to be perfect to be useful.
Kind of like building a Turing machine holes-in-paper-tape version of
a program, it can be an interesting exercise but practically it's
useless.
Read in transcript of congressional testimony on NSA surveillance.
Split into one string for each line.
Read one line every second.
If a line contains the word "terrorism" make a sound.
User takes a drink.
Totally useful. :)
What is it about boxes connected with lines that you think makes this
difficult?
-Jonathan
Martin
On 2014-02-08 03:14, Jonathan Wilkes wrote:
On 02/08/2014 01:26 AM, Martin Peach wrote:
You can manipulate strings in pdlua and only export the symbols you
want; yes you need to learn lua but it's not very hard.
That's good practical advice for getting work done with strings atm. But
it's irrelevant to getting decent string manipulation within Pd, meaning
using boxes connected with wires.
The reason for wanting to do string manipulation within Pd is just as
obvious as the question that I didn't have to ask and which you
addressed after your semicolon.
-Jonathan
Martin
On 2014-02-08 01:10, Jonathan Wilkes wrote:
On 02/06/2014 01:53 AM, Chris McCormick wrote:
On 06/02/14 06:29, pured...@11h11.com wrote:
but pd is not really good with strings afaik
Maybe soon:
https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f13513c77f0796d21b/
https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190fcee7c6fa5627/
:)
One of the reasons (I think) the string manipulation libs in Pd
extended
haven't caught on is because they seem to force users to care directly
about character codes. If I want to pass the string "hello{world}"
around in Pd, I should not have to know the codes for curly braces
just
to create that string in an object box.
To work, this will require a new set of GUI classes that allow the
user
to type strings that get saved underneath as character codes, as
well as
display lists of character codes as a string in the patch. I don't
know
any externals that do this, but it shouldn't be hard if you're sending
the text to the GUI as floats. Also, you need i/o classes to read
from
and write to files without having to pass through lists of symbols and
floats as intermediaries. Otherwise, you will lose data on the read.
Finally, you can't leverage any of the extant symbol manipulation
tools,
because then you run into symbol-table growth, dollsym
substitutions/escapes, and all the other problems that I assume are
the
reason for introducing lists of character codes. Otherwise you're
just
pushing the current problems users have with symbols to the edges
of the
new string library.
I understand the desire for this approach, and it's probably less work
than making symbols deallocatable. But if the user has to stare at
character codes just to get around the limitations of symbol atoms,
they'll probably just use symbol atoms and work within Pd's current
limitations for string processing.
-Jonathan
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
__
Re: [PD] check mail with pd ?
A few years ago I implemented a patch for strings in Pd that adds a
string or blob type that allows (I think) for what you are describing. I
believe it's still part of Pd extended, but Miller didn't like it for
some reason.
I prefer to manipulate strings in a another language as it just seems
like a lot of work to make it happen with boxes and wires when you can
just call string functions in a high level language.
Kind of like building a Turing machine holes-in-paper-tape version of a
program, it can be an interesting exercise but practically it's useless.
Martin
On 2014-02-08 03:14, Jonathan Wilkes wrote:
On 02/08/2014 01:26 AM, Martin Peach wrote:
You can manipulate strings in pdlua and only export the symbols you
want; yes you need to learn lua but it's not very hard.
That's good practical advice for getting work done with strings atm. But
it's irrelevant to getting decent string manipulation within Pd, meaning
using boxes connected with wires.
The reason for wanting to do string manipulation within Pd is just as
obvious as the question that I didn't have to ask and which you
addressed after your semicolon.
-Jonathan
Martin
On 2014-02-08 01:10, Jonathan Wilkes wrote:
On 02/06/2014 01:53 AM, Chris McCormick wrote:
On 06/02/14 06:29, pured...@11h11.com wrote:
but pd is not really good with strings afaik
Maybe soon:
https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f13513c77f0796d21b/
https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190fcee7c6fa5627/
:)
One of the reasons (I think) the string manipulation libs in Pd extended
haven't caught on is because they seem to force users to care directly
about character codes. If I want to pass the string "hello{world}"
around in Pd, I should not have to know the codes for curly braces just
to create that string in an object box.
To work, this will require a new set of GUI classes that allow the user
to type strings that get saved underneath as character codes, as well as
display lists of character codes as a string in the patch. I don't know
any externals that do this, but it shouldn't be hard if you're sending
the text to the GUI as floats. Also, you need i/o classes to read from
and write to files without having to pass through lists of symbols and
floats as intermediaries. Otherwise, you will lose data on the read.
Finally, you can't leverage any of the extant symbol manipulation tools,
because then you run into symbol-table growth, dollsym
substitutions/escapes, and all the other problems that I assume are the
reason for introducing lists of character codes. Otherwise you're just
pushing the current problems users have with symbols to the edges of the
new string library.
I understand the desire for this approach, and it's probably less work
than making symbols deallocatable. But if the user has to stare at
character codes just to get around the limitations of symbol atoms,
they'll probably just use symbol atoms and work within Pd's current
limitations for string processing.
-Jonathan
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
On 02/08/2014 01:26 AM, Martin Peach wrote:
You can manipulate strings in pdlua and only export the symbols you
want; yes you need to learn lua but it's not very hard.
That's good practical advice for getting work done with strings atm.
But it's irrelevant to getting decent string manipulation within Pd,
meaning using boxes connected with wires.
The reason for wanting to do string manipulation within Pd is just as
obvious as the question that I didn't have to ask and which you
addressed after your semicolon.
-Jonathan
Martin
On 2014-02-08 01:10, Jonathan Wilkes wrote:
On 02/06/2014 01:53 AM, Chris McCormick wrote:
On 06/02/14 06:29, pured...@11h11.com wrote:
but pd is not really good with strings afaik
Maybe soon:
https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f13513c77f0796d21b/
https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190fcee7c6fa5627/
:)
One of the reasons (I think) the string manipulation libs in Pd extended
haven't caught on is because they seem to force users to care directly
about character codes. If I want to pass the string "hello{world}"
around in Pd, I should not have to know the codes for curly braces just
to create that string in an object box.
To work, this will require a new set of GUI classes that allow the user
to type strings that get saved underneath as character codes, as well as
display lists of character codes as a string in the patch. I don't know
any externals that do this, but it shouldn't be hard if you're sending
the text to the GUI as floats. Also, you need i/o classes to read from
and write to files without having to pass through lists of symbols and
floats as intermediaries. Otherwise, you will lose data on the read.
Finally, you can't leverage any of the extant symbol manipulation tools,
because then you run into symbol-table growth, dollsym
substitutions/escapes, and all the other problems that I assume are the
reason for introducing lists of character codes. Otherwise you're just
pushing the current problems users have with symbols to the edges of the
new string library.
I understand the desire for this approach, and it's probably less work
than making symbols deallocatable. But if the user has to stare at
character codes just to get around the limitations of symbol atoms,
they'll probably just use symbol atoms and work within Pd's current
limitations for string processing.
-Jonathan
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
You can manipulate strings in pdlua and only export the symbols you
want; yes you need to learn lua but it's not very hard.
Martin
On 2014-02-08 01:10, Jonathan Wilkes wrote:
On 02/06/2014 01:53 AM, Chris McCormick wrote:
On 06/02/14 06:29, pured...@11h11.com wrote:
but pd is not really good with strings afaik
Maybe soon:
https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f13513c77f0796d21b/
https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190fcee7c6fa5627/
:)
One of the reasons (I think) the string manipulation libs in Pd extended
haven't caught on is because they seem to force users to care directly
about character codes. If I want to pass the string "hello{world}"
around in Pd, I should not have to know the codes for curly braces just
to create that string in an object box.
To work, this will require a new set of GUI classes that allow the user
to type strings that get saved underneath as character codes, as well as
display lists of character codes as a string in the patch. I don't know
any externals that do this, but it shouldn't be hard if you're sending
the text to the GUI as floats. Also, you need i/o classes to read from
and write to files without having to pass through lists of symbols and
floats as intermediaries. Otherwise, you will lose data on the read.
Finally, you can't leverage any of the extant symbol manipulation tools,
because then you run into symbol-table growth, dollsym
substitutions/escapes, and all the other problems that I assume are the
reason for introducing lists of character codes. Otherwise you're just
pushing the current problems users have with symbols to the edges of the
new string library.
I understand the desire for this approach, and it's probably less work
than making symbols deallocatable. But if the user has to stare at
character codes just to get around the limitations of symbol atoms,
they'll probably just use symbol atoms and work within Pd's current
limitations for string processing.
-Jonathan
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
On 02/06/2014 01:53 AM, Chris McCormick wrote:
On 06/02/14 06:29, pured...@11h11.com wrote:
but pd is not really good with strings afaik
Maybe soon:
https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f13513c77f0796d21b/
https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190fcee7c6fa5627/
:)
One of the reasons (I think) the string manipulation libs in Pd extended
haven't caught on is because they seem to force users to care directly
about character codes. If I want to pass the string "hello{world}"
around in Pd, I should not have to know the codes for curly braces just
to create that string in an object box.
To work, this will require a new set of GUI classes that allow the user
to type strings that get saved underneath as character codes, as well as
display lists of character codes as a string in the patch. I don't know
any externals that do this, but it shouldn't be hard if you're sending
the text to the GUI as floats. Also, you need i/o classes to read from
and write to files without having to pass through lists of symbols and
floats as intermediaries. Otherwise, you will lose data on the read.
Finally, you can't leverage any of the extant symbol manipulation tools,
because then you run into symbol-table growth, dollsym
substitutions/escapes, and all the other problems that I assume are the
reason for introducing lists of character codes. Otherwise you're just
pushing the current problems users have with symbols to the edges of the
new string library.
I understand the desire for this approach, and it's probably less work
than making symbols deallocatable. But if the user has to stare at
character codes just to get around the limitations of symbol atoms,
they'll probably just use symbol atoms and work within Pd's current
limitations for string processing.
-Jonathan
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
On 06/02/14 06:29, pured...@11h11.com wrote: > but pd is not really good with strings afaik Maybe soon: https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f13513c77f0796d21b/ https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190fcee7c6fa5627/ :) Cheers, Chris. -- http://mccormick.cx/ #N canvas 213 266 450 449 10; #X obj 50 253 list tosymbol; #X obj 50 87 list fromsymbol; #X obj 50 275 list prepend set; #X obj 50 297 list trim; #X obj 71 133 list split 1; #X obj 152 133 t l; #X msg 50 58 symbol dog/cat/mouse; #X msg 71 177 45; #X obj 71 155 sel 47; #X obj 71 200 list append; #X obj 146 200 t l; #X obj 50 226 list; #X obj 50 109 t b a b; #X obj 220 87 list fromsymbol; #X obj 241 133 list split 1; #X obj 322 133 t l; #X msg 220 58 symbol dog/cat/mouse; #X obj 241 200 list append; #X obj 316 200 t l; #X obj 220 226 list; #X obj 220 109 t b a b; #X text 54 30 "replace"; #X text 225 24 "split"; #X obj 220 253 list tosymbol; #X obj 220 275 print; #X obj 241 155 sel 47; #X obj 241 177 t b b; #X msg 50 319; #X connect 0 0 2 0; #X connect 1 0 12 0; #X connect 2 0 3 0; #X connect 3 0 27 0; #X connect 4 0 8 0; #X connect 4 1 5 0; #X connect 5 0 4 0; #X connect 6 0 1 0; #X connect 7 0 9 0; #X connect 8 0 7 0; #X connect 8 1 9 0; #X connect 9 0 10 0; #X connect 9 0 11 1; #X connect 10 0 9 1; #X connect 11 0 0 0; #X connect 12 0 11 0; #X connect 12 1 4 0; #X connect 12 2 9 1; #X connect 13 0 20 0; #X connect 14 0 25 0; #X connect 14 1 15 0; #X connect 15 0 14 0; #X connect 16 0 13 0; #X connect 17 0 18 0; #X connect 17 0 19 1; #X connect 18 0 17 1; #X connect 19 0 23 0; #X connect 20 0 19 0; #X connect 20 1 14 0; #X connect 20 2 17 1; #X connect 23 0 24 0; #X connect 25 0 26 0; #X connect 25 1 17 0; #X connect 26 0 19 0; #X connect 26 1 17 1; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
On 02/05/2014 05:29 PM, pured...@11h11.com wrote: yes possible, for example using py/ext with a script like this one: http://libgmail.sourceforge.net/ but pd is not really good with strings afaik If you use Pd and have a use case where you're controling both the sending and receiving of the messages, then you can limit the message content to use only what Pd's message parser can handle. Also, make sure the machine you're using has never had or will never have anything of interest on it. On the other hand, I guess you could leave a Bitcoin wallet on there and think of your impending hack as a virtual Halloween treat. -Jonathan à+ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
Le 05/02/2014 15:35, Fero Kiraly a écrit : > is it possibile ? > > thanks. > > fero > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list Just try it with [tcpclient] on Ubuntu and it works fine. See patch attached. ++ Jack get_mail.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-02-05 16:02, IOhannes m zmoelnig wrote: > On 2014-02-05 15:35, Fero Kiraly wrote: >> is it possibile ? > > > depends on what you really want to do. > > i've once written an MTA in Pd (that is a mail-server, as opposed > to the mail-client you want). http://puredata.info/downloads/pd-mail/ the project page speaks of having both "MTA" and "MUA" implemented, but in this context "MUA" (user client) really only means "sending MUA" and not "MUA for reading emails" fgamdsr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJS8lrAAAoJELZQGcR/ejb4dzwP/2Bn9huTNqP6QBhEKRZK0S2u JMJe47EuvV/UCk5HpFqV3mlkEztZ70j4IVRczGXPrWd5Uh42XEibxNN1v7REu5KU xLWBIx8TOpPJ1CgbaezfFJ4vVDhrK7zMqjsoFZHyBlrZhAXa8nq8ndAnoWxqsA2W 0uBO/yzCbXsQDS4n6rF9vWB10iDSKQNXoI60PcZIgEY5L43MJFNiB4amoB452BPy 6OO4SyVT0xXwv5lA/XOdPJSTHUGMBFf5GwMD8/XmbnFQOo3bCc+7p/6sZf0wXRp+ YF/bbBNYq2VyDfplhaz8a1wc5D/fLWvysWFeurSj6dGbQtNoF1ogLyFXerCbWiLJ XOkEV1/IthHcSX7kDnYa7/QQzgarwesATDRU9vPtz6mHGlcGJpckH56bne6u90ju LLZFaCH3JNGff1MuzuPuRt3auIUX8jtHa2E7Oo6XaNV57pA+cH5hZuqVck7xnNOm 2E2sFeDg0PdST7BEwal6KkdkbsGdv6RXgKyMmkpHZhbjW5JENSswCKOLnx3iMvya Ov/iHHwGjfcNbCrqVC5dZP6yRcx0HGbRsWtDQLNR5CgfW+IZ2UGYhy7geDswdpJV TIu6tnXg89U4dYyt4PmAQrr4cQEDa8V3OH1YXVtUvrPoU78s+p1OFWzfXupu+2on 6Y8CQB5Tgta5bcRw59tm =SHSB -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-02-05 15:35, Fero Kiraly wrote: > is it possibile ? > depends on what you really want to do. i've once written an MTA in Pd (that is a mail-server, as opposed to the mail-client you want). communicating with an imap server is not very complicated (as long as there is no encryption involved), so it should be *quite* easy to do that in Pd. i guess the biggest problem is to present the email(s) to the user. fgasmdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJS8lJ7AAoJELZQGcR/ejb4xYYP/is/dW5C7Ix0ugSHHspVAlO/ wzn+9NWjjrHXECNvc4q/KgweAWs+Eq7Y7ZpzfnXxt++4/SLunxd8pxQ5TPQj+ha7 MoLYwPByFJ9ChASJbnpriQzB3lKA9zJZ+q40TGJafMg+j8l7XsLevXzpzg12OV4p cOqAbVYC4YSrAbp0jwrBm6M+3BE+yc2dooNOdRFU5/Lwf46omJwv2sc+Wasny5OQ s9lFONozJOuFMyZAULsWBjnfmc2ZiBbXpjSV2XQ0GCYiE8DjBJAYdg17/eg0/QeH pQtdj+Hd5Rkb14IeU3GyqzaKZZPoH603ao7vBxz0a1eK9y03ggIWpSfwus3Q901w jwLefM1zoIap8Qsh8CaNZTv/Qd5iWuyZJ9g8g5m1BY1FSoigEUDXBTMU2DlT20Ul uCumvVzHMNyxzLaoyECdIP4rIlABedVXV/+zPEFt/TvsucIcFU9iMv8HSoEL4+Xc 2zKb5BKK/v/FCcCzLKoL1JRa67C+Tkgvd2hqpFcgJujBPaf6dYEskZE0ZLWRWWkW ZGrpDi7aQPghXR/69bdJnCMsHrqbWXq3MQibmnkiKZPiNiA7nOcWqFXw/0oX9LCD RJFhnEKwBpw69a1ZqtvIvP1kY5P37sqGVvGi4XjnNErhGfjMZ/alPgUV2bxMajK+ EMQKHlpjACEeuJEmhZl2 =mOjE -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
yes possible, for example using py/ext with a script like this one: http://libgmail.sourceforge.net/ but pd is not really good with strings afaik à+ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] check mail with pd ?
is it possibile ? thanks. fero ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
