S99-glossary.pod
Log Message:
---
added NCI
On Mon Jan 12 07:34:33 2009, donaldhunter wrote:
> It appears that rakudo changes committed over the weekend have broken
NCI.
> The last known working revision was #35300 for ext/SQLite3/t/test.p6
which
> is crashing on #35440.
> You'll need to patch ext/SQLite3/Makefile.PL
On Mon, Jan 12, 2009 at 07:34:33AM -0800, Donald Hunter wrote:
> It appears that rakudo changes committed over the weekend have broken NCI.
> The last known working revision was #35300 for ext/SQLite3/t/test.p6 which
> is crashing on #35440.
> You'll need to patch ext/SQLite3/Ma
grind.pid12075
Description: Binary data
# New Ticket Created by Donald Hunter
# Please include the string: [perl #62244]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=62244 >
It appears that rakudo changes committed over the weekend have broken NCI.
The l
an uninitialized string. specifically, the pcc_params_signature NCI
attribute is null. not sure if this corresponds to a specific parrot
test...
creating the signature as a constant string appears to cause this problem,
as removing PObj_constant_FLAG from src/pmc/nci.pmc:82 "fixes" the i
No objections and no problems, closing ticket.
Hearing no objections, and because I needed it to be able to do tests
with mysqlclient, applied in r30790
--
Salu2
# New Ticket Created by NotFound
# Please include the string: [perl #58438]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=58438 >
I was doing a simple test of NCI calls with the xlib function
XDisplayName, and found t
as a calling convention is usually used consistently, and
> providing defaults for well known libraries.
tewk's C99 parser / NCI JIT code should handle part of this (and could
be expanded to do more). We may want to just settle on extending that
work as needed, rather than trying to shoehorn i
AFAICT, Parrot uses function pointers for NCI. This means NCI uses
whatever calling convention the compiler uses by default.
Unfortunately, there's More Than One Way To Do It.
On Windows, there's the C calling convention (__cdecl), which is usually
used by default by the Visual C+
On Sunday 27 April 2008 18:08:08 Mark Glines wrote:
> In the future, INTVAL will probably be 128 bits for some platforms.
> I'd really like to see a set of fixed-width types (similar to what p5
> has for pack and unpack), so you have the option of "native int" or
> "exactly 32 bits" or whatever yo
,12 @@
my %func_call_assign = (
p => "return_data = ",
i => "return_data = ",
+2 => "return_data = ",
3 => "return_data = ",
-2 => "return_data = ",
4 => "return_data = ",
+5 =>
g C or C. There is no way to
correctly handle this with Parrot's NCI signature types. Currently both
MySQL and OpenGL are just substituting C instead, which will work
on 64-bit architectures, but fail miserably on 32-bit arches.
(I wish we could just insist that INTVAL be 64 bits everywhere,
On Sat, 19 Apr 2008 11:26:13 +0530
"Senaka Fernando" <[EMAIL PROTECTED]> wrote:
> Hi Mark,
>
> What does the fix to 't/codingstd/c_indent.t' do? Does it ignore
> anything inside #ifdef __cplusplus blocks?
Yes. This lets us add any g++-specific stuff without throwing off the
indentation.
Mark
Hi Mark,
What does the fix to 't/codingstd/c_indent.t' do? Does it ignore anything
inside #ifdef __cplusplus blocks?
Regards,
Senaka
On Sat, Apr 19, 2008 at 6:38 AM, Mark Glines via RT <
[EMAIL PROTECTED]> wrote:
> On Thu Apr 17 09:03:57 2008, infinoid wrote:
> > On Tue Apr 15 02:58:18 2008, [E
I've been working on parsing the function prototypes in the
GL/GLU/GLUT/GLX headers, in preparation for generating bindings for all
of them during the Parrot build.
Currently my prototype parser is able to compute NCI signatures for all
but 14 out of the 1835 total prototypes found in my sys
f
+#ifdef __cplusplus
+}
+#endif
+
/*
=back
Hi all,
The provided patch makes the NCI test C++ compatible.
Regards,
Senaka
;Grafman" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, March 26, 2008 3:44 PM
Subject: Re: Extending Parrot NCI callback functionality Options
On Wed, 2008-03-26 at 09:31 -0700, Grafman wrote:
He lives! Just kidding, I know you'v
ry
> distros for Windows (PPMs) works on any Windows box with an OpenGL driver
> (standard on NT/XP/Vista) - this doesn't work for other platforms.
I keep thinking we should just do runtime stub patching everywhere, as
with GLee/GLEW/SDL/etc. The nice thing is that this can be done
"current" context state). As such, GLUT was
> designed to assume single-threaded uses - which is why it's callbacks
> do not have user data.
>
> It has been suggested that one might "fix" Parrot's NCI to support
> generic callbacks. There's
not use callbacks, it is assumed to be single-
> threaded (there's a "current" context state).
Well, at least that there is only one thread doing rendering; there may
freely be other threads doing non-rendering tasks.
> It has been suggested that one might "fix" Parrot&#x
-oriented for server-
side use.
While OpenGL itself does not use callbacks, it is assumed to be single-
threaded (there's a "current" context state). As such, GLUT was
designed to assume single-threaded uses - which is why it's callbacks
do not have user data.
It has been sugg
# New Ticket Created by Geoffrey Broadwell
# Please include the string: [perl #50360]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50360 >
Parrot's NCI callback subsystem design will not work (and cannot be
chromatic wrote:
Here's my crazy idea.
When you register a callback into PIR from C, you need to pass a few
arguments: the interpreter into which to call, the PMC Sub to call, and the C
signature of the C function which gets called from C.
I presume that the PIR function will get called thro
chromatic wrote:
On Friday 18 January 2008 20:25:16 Allison Randal wrote:
It's true that the generalized solution for varying callback signatures
doesn't exist yet, but it's easy enough to create your own C callback
layer, with a separate C function for each callback you need. (Note, not
one-pe
On Jan 16, 2008, at 7:39 PM, Geoffrey Broadwell wrote:
I am starting to implement a GLUT and OpenGL binding for Parrot. GLUT
is extremely callback-oriented.
Unfortunately, none of the GLUT callbacks fall within the current
limitations on Parrot NCI callbacks.
As you've discovered, call
Here's my crazy idea.
When you register a callback into PIR from C, you need to pass a few
arguments: the interpreter into which to call, the PMC Sub to call, and the C
signature of the C function which gets called from C.
I presume that the PIR function will get called through one of the exter
On Friday 18 January 2008 20:25:16 Allison Randal wrote:
> It's true that the generalized solution for varying callback signatures
> doesn't exist yet, but it's easy enough to create your own C callback
> layer, with a separate C function for each callback you need. (Note, not
> one-per-signature,
On Sat, 2008-01-19 at 17:25 +1300, Allison Randal wrote:
> Geoffrey Broadwell wrote:
> > On Wed, 2008-01-16 at 22:38 -0700, Paul Seamons wrote:
> >>> I am starting to implement a GLUT and OpenGL binding for Parrot.
> [...]
> > I don't often get concentrated time
> > to help out with Parrot and Perl
Geoffrey Broadwell wrote:
On Wed, 2008-01-16 at 22:38 -0700, Paul Seamons wrote:
I am starting to implement a GLUT and OpenGL binding for Parrot.
[...]
I don't often get concentrated time
to help out with Parrot and Perl 6, but I have some now. If this is
going to be blocked indefinitely, my
think I got a little farther, but I'm blocked now
just as you were, on the same problem.
> It appears that NCI is on the roadmap a couple of months out (or more), but
> that when it is done it will be done right - for some definition of right.
I think that Allison hand-waved over exactly
spatch information in a user data argument.
It appears that NCI is on the roadmap a couple of months out (or more), but
that when it is done it will be done right - for some definition of right.
I would've put more work into a temporary solution, but real life has
interfered.
I'm glad
Right now, Parrot's support for NCI callbacks (C code calling back into
PIR code) is relatively limited. In particular, there are at least the
following limitations:
1. The return type must be void (C library does not expect a response).
2. The callback must have exactly two arguments
Sorry, essentially what I'm asking is if i can pass a pir method as a
function pointer on a c call.
essentially what I'm looking to do is get into the message pump on
windows, and I'm trying to keep all of the code within pir.
I'm trying to see how many hoops I need to do in order to write a
On Monday 07 January 2008 09:22:43 robby wrote:
> With skimming across the past 400 or so messages on this list I'm not
> exactly sure if this would be the correct list to post this, but I have
> a quick question regarding NCI's and callbacks.
>
> I've read http://www.parrotcode.org/docs/pdd/pdd16
With skimming across the past 400 or so messages on this list I'm not
exactly sure if this would be the correct list to post this, but I have
a quick question regarding NCI's and callbacks.
I've read http://www.parrotcode.org/docs/pdd/pdd16_native_call.htm and
nci.t and I haven't came up with
These statements are removed in r23981.
kjs
On Dec 16, 2007 4:16 PM, Allison Randal <[EMAIL PROTECTED]> wrote:
> Jonathan Worthington wrote:
> > Hi,
> >
> > At the top of the NCI PMC, there are these comments:
> >
> > --
> > Invoking an NCI funct
Jonathan Worthington wrote:
Hi,
At the top of the NCI PMC, there are these comments:
--
Invoking an NCI function changes some registers according to PDD 3.
The caller has to preserve registers if needed.
--
Am I right in thinking that's no longer true?
Yes, PDD 3 no longer uses spe
Hi,
At the top of the NCI PMC, there are these comments:
--
Invoking an NCI function changes some registers according to PDD 3.
The caller has to preserve registers if needed.
--
Am I right in thinking that's no longer true?
Thanks,
Jonathan
On Nov 26, 7:42 am, [EMAIL PROTECTED] (Will Coleda)
wrote:
> # New Ticket Created by Will Coleda
> # Please include the string: [perl #47826]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=47826>
>
> T
# New Ticket Created by Will Coleda
# Please include the string: [perl #47826]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=47826 >
The NCI information in docs/books is out of date. per codyl on
#parrot, the c
mechanism in NCI?
- Is this a relatively sane/clean way to do it?
- Is there a better way to generate the functions for each signature?
- What is the right way to store that global user_data until the callbacks
are fired?
NCI isn't fully specified yet, but I'll outline some of our current
should be used to run the sub stored in the PMC. The pdd says
that outside the two provided signatures, anybody wanting to implement
NCI connections to callback functions will need to do some hand C
coding. Hand C coding isn't at all bad, but it would be nice to have
a generic mechanism for st
should be used to run the sub stored in the PMC. The pdd says
that outside the two provided signatures, anybody wanting to implement
NCI connections to callback functions will need to do some hand C
coding. Hand C coding isn't at all bad, but it would be nice to have
a generic mechanism for st
On Apr 6, 2007, at 11:48 AM, chromatic wrote:
On Friday 06 April 2007 00:58, Joshua Isom wrote:
What if we had a repository, ala pugs with it's "open" commits, solely
for people to commit tests. It could help improve bug discovery and
test coverage, as well as ambiguity about features in par
On Friday 06 April 2007 00:58, Joshua Isom wrote:
> What if we had a repository, ala pugs with it's "open" commits, solely
> for people to commit tests. It could help improve bug discovery and
> test coverage, as well as ambiguity about features in parrot. Then
> developers could just update it
On Apr 5, 2007, at 5:45 PM, Leopold Toetsch wrote:
Am Donnerstag, 5. April 2007 00:39 schrieb Jonathan Worthington:
Don't really need a policy to tell me that breaking stuff for
languages
folks sucks. :-) I try hard to avoid it, but unfortunately stuff slips
through the net occasionally. In t
Am Donnerstag, 5. April 2007 00:39 schrieb Jonathan Worthington:
> Don't really need a policy to tell me that breaking stuff for languages
> folks sucks. :-) I try hard to avoid it, but unfortunately stuff slips
> through the net occasionally. In this case, I wasn't even aware that you
> could use
Jonathan Worthington wrote:
Anyway, fixed in r17982. May need a realclean - I had to do one anyway
to run the buildtools tests.
Awesome. Works for me even without realclean.
Thanks!
Allison
Allison Randal wrote:
This is a leftover from the old days when the way to override a vtable
method was to define a method with an '__' name, so they never
conflicted.
Not really - this was a conflict in the names of the methods at a C
level. The '__' prefix was a PIR-level thing. In PIR we ma
Allison Randal wrote:
For me too, even after a 'make realclean' on Parrot. In the interests
of our developing policy on a stable trunk: Jonathan, fix the problem
for Lua or revert the change before continuing with further development.
Don't really need a policy to tell me that breaking stuff for
François PERRAD wrote:
This new behavior breaks the build of Lua PMC.
Argh, sorry. :-( Thanks for the detailed bug report - I know where the
problem is, and am working on a fix.
Jonathan
Jonathan Worthington wrote:
Hi,
I was working on starting to move class functionality into v-table
methods, as discussed on list recently. However, I hit an interesting
issue - you cannot have a METHOD or PCCMETHOD with the same name as a
vtable method. We need to be able to do that to implem
François PERRAD wrote:
Anyway, hope this is agreeable, and please do report any issues.
This new behavior breaks the build of Lua PMC.
For me too, even after a 'make realclean' on Parrot. In the interests of
our developing policy on a stable trunk: Jonathan, fix the problem for
Lua or reve
At 01:33 04/04/2007 +0100, Jonathan Worthington wrote:
Hi,
I was working on starting to move class functionality into v-table
methods, as discussed on list recently. However, I hit an interesting
issue - you cannot have a METHOD or PCCMETHOD with the same name as a
vtable method. We need to b
Hi,
I was working on starting to move class functionality into v-table
methods, as discussed on list recently. However, I hit an interesting
issue - you cannot have a METHOD or PCCMETHOD with the same name as a
vtable method. We need to be able to do that to implement the interface
specified
g
> changes pending?).
> If desired, I'd be happy to do more updates. Please let me know.
> At least there's full working code to do a simple NCI invocation.
Please do. There are no big changes pending.
Thanks, applied as r17164.
-- c
hi,
I've been playing with NCI calls and more fun (embedding a Parrot, that
runs a PIR program, which invokes a C function, that then invokes a PIR
callback function).
As a result, I added a simple example to PDD16. I didnt' put too much
work in it (there are many more places tha
onnectdb'('') # assume table = user is present
I have PostgreSQL installed, but this assumption doesn't work for me. I've
checked in a skip for the remaining tests in this case, as there's no point
in running them. (They cause NCI assertion failures, as the N
eter as the parent
argument to Parrot_new()).
> You migh also grep for enter_nci_method in src/pmc/*.c - all METHODs in
> .pmc are converted to NCI calls in the .c files with appropriate
> signatures.
That ought to work.
-- c
>
> I don't see documentation for the S or I parameters anywhere in the NCI
> PDD. Is there a better place for them?
src/call_list.txt is probably the best place to look. And a good one to look
into occasionally, I've mixed up 'I' and 'J' - sorry.
> I
On Friday 21 July 2006 00:57, Leopold Toetsch wrote:
> This can't work for several reasons:
>
> 1) the NCI call signatures don't match the C functions' args:
>
> .store_nci_func( 'const_string', 'ppt' )
>
> sh
Am Freitag, 21. Juli 2006 07:53 schrieb chromatic:
> Should this code work? I think so.
This can't work for several reasons:
1) the NCI call signatures don't match the C functions' args:
.store_nci_func( 'const_string', 'ppt' )
should be:
Should this code work? I think so.
I don't think it's necessarily *good* practice, but I do think it should work.
-- c
Thanks, appled as r13221
# New Ticket Created by Rene Hangstrup Møller
# Please include the string: [perl #39771]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39771 >
The win32 example in parrot/examples/nci/win32api.pir fails because
On Friday 03 March 2006 02:41, Tim Bunce wrote:
> Any news on this? Is it okay? Should I send it via parrotbug?
It looked good to me. I say check it in and see what the smokes do.
-- c
gt; +# Edited copy of mysql.h using vi by doing g/, *$/j (repeat) then g/\* *$/j
> (repeat)
> +# to get all functions on one line each.
> +# Extracted list of api func names from
> http://dev.mysql.com/doc/refman/4.1/en/c-api-functions.html
> +# and copied to a temporary file to clean up (mysql_a
ripped down to bare names and merged into one line separated by |
+# then egrep -w `cat mysql_api_names.txt` mysql.h > mysql_api.ncidef
+# then edit mysql_api.ncidef in vi: %s/^/ # /
+# to create space for nci signatures and to use original definition as a #
comment.
+# This method isn'
On Feb 14, 2006, at 18:29, Tim Bunce wrote:
I'll aim to work up a patch this week.
Great, thanks.
The runtime dlfunc code will need to be altered to normalize away the
trailing v so old code won't break. Should it warn about that?
Yes, a warning please.
Tim.
leo
On Feb 14, 2006, at 21:45, chromatic wrote:
To avoid confusion, I suggest requiring that functions returning void
always
use 'v' and disallowing the signature ''.
Exactly my thoughts too.
leo
On Tuesday 14 February 2006 05:48, Leopold Toetsch wrote:
> I'd say, we should drop all the '?v' variants. The extra 'v' doesn't
> cover any information, it's just causing an init call to the argument
> passing code.
To avoid confusion, I suggest requiring that functions returning void always
us
On Tue, Feb 14, 2006 at 02:48:41PM +0100, Leopold Toetsch wrote:
> Tim Bunce wrote:
> >What's the difference between 'v' and '' for NCI function parameters?
>
> There isn't any, except the extra 'v' char.
>
> >I ask because bot
Tim Bunce wrote:
What's the difference between 'v' and '' for NCI function parameters?
There isn't any, except the extra 'v' char.
I ask because both 'fv' and 'f' are in src/call_list.txt
Yeah.
In fact there are several 'd
What's the difference between 'v' and '' for NCI function parameters?
Here, for example, is the code for 'fv' and 'f':
static void
pcf_f_v(Interp *interpreter, PMC *self)
{
typedef float (*func_t)(void);
func_t pointer;
On Jan 2, 2006, at 19:36, Dan Sugalski wrote:
The big hang up has been the removal of the T and L parameter types
for NCI calls. T was a string pointer array and L was a long array.
[ ... ]
Are there alternatives? The documentation for this stuff is worse now
than when I wrote it
I just went, after ages, and sync'd up with a current parrot for my
work project. Fixing things to work with the changes has been...
interesting.
The big hang up has been the removal of the T and L parameter types
for NCI calls. T was a string pointer array and L was a long array.
Th
d stuff. I also need to clarify a
few things; such a when I allocate some PMCs in C whether I need to
mark them so that they aren't swept away by a DOD (I suspect so).
Some known issues:
* Can't clone the NCI object
* compilers/pge/mklib.pir might die during the build; I can't d
On Mon, 2005-10-31 at 20:12 +, Nick Glencross wrote:
> I certainly agree about what was being said about supporting multiple
> backends as it protects us against future nasty platforms. However, I'm
> unclear what the benefits of the favoured option of using JIT code was;
> that sounds like
Garrett Goebel wrote:
Nick Glencross wrote:
As mentioned on the list yesterday I started evaluating ffcall
as a way of providing NCI functionality.
http://www.haible.de/bruno/packages-ffcall.html
I actually really like the current NCI implementation, although
it suffers from a large nci.c
Nick Glencross wrote:
>
> As mentioned on the list yesterday I started evaluating ffcall
> as a way of providing NCI functionality.
>
> http://www.haible.de/bruno/packages-ffcall.html
>
> I actually really like the current NCI implementation, although
> it suffers fro
On Oct 31, 2005, at 7:49, John Lenz wrote:
On Fri, October 28, 2005 2:22 pm, Nick Glencross said:
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a
way
of providing NCI functionality.
http://www.haible.de/bruno/packages-ffcall.html
I am a SWIG (www.swig.org
On Fri, October 28, 2005 2:22 pm, Nick Glencross said:
> Guys,
>
> As mentioned on the list yesterday I started evaluating ffcall as a way
> of providing NCI functionality.
>
> http://www.haible.de/bruno/packages-ffcall.html
I am a SWIG (www.swig.org) developer, and I recent
Nick Glencross wrote:
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a
way of providing NCI functionality.
Ok, here's an updated version with (hopefully) working callbacks -- at
least enough for a POC.
If you tried out my previous version, run 'rm
Leopold Toetsch wrote:
On Oct 28, 2005, at 22:22, Nick Glencross wrote:
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a
way of providing NCI functionality.
http://www.haible.de/bruno/packages-ffcall.html
I've downloaded it and had a short look into so
Nick Glencross wrote:
Nick Glencross wrote:
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a
way of providing NCI functionality.
I seem to be seeing rather strange, and it's probably a
misunderstanding on my part.
Ok, I see what the problem is. PMC_data(
Nick Glencross wrote:
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a
way of providing NCI functionality.
I seem to be seeing rather strange, and it's probably a misunderstanding
on my part.
I've pinched the GET_NCI_x(n) macros and accompanying
On Oct 28, 2005, at 22:22, Nick Glencross wrote:
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a
way of providing NCI functionality.
http://www.haible.de/bruno/packages-ffcall.html
I've downloaded it and had a short look into sources. The list of
supp
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a way
of providing NCI functionality.
http://www.haible.de/bruno/packages-ffcall.html
I actually really like the current NCI implementation, although it
suffers from a large nci.c file and all the usable prototypes
On Oct 25, 2005, at 23:32, Nick Glencross wrote:
I was looking at callbacks the other evening. Am I right in thinking
that only two callback prototypes are supported, or have I missed a
trick there as well?
That's right. There are 2 callbacks (functions with 2 arguments only),
one with the
Nick Glencross schrieb:
I was looking at callbacks the other evening. Am I right in thinking
that only two callback prototypes are supported, or have I missed a
trick there as well?
Yes, I think that hasn't changed since I've looking into interfacing
Parrot with libsyck. As far as I rememb
Leopold Toetsch via RT wrote:
On Oct 23, 2005, at 17:08, Nick Glencross (via RT) wrote:
Guys,
call_list.txt lists 'T' and 'L' as being prototypes for passing arrays
to nci functions, but no implementation exists in build_nativecall.pl.
This patch provides an implementa
On Oct 23, 2005, at 17:08, Nick Glencross (via RT) wrote:
Guys,
call_list.txt lists 'T' and 'L' as being prototypes for passing arrays
to nci functions, but no implementation exists in build_nativecall.pl.
This patch provides an implementation, as well as new tests.
I d
for passing arrays
to nci functions, but no implementation exists in build_nativecall.pl.
This patch provides an implementation, as well as new tests.
Someone might raise the point as to whether the data should be read back
into parrot's array, but this is generally going to be tricky and a j
Applied as r9496. Thanks.
-J
we skip two nci tests which are causing hangs on HP-UX and
as such prevent smoke testing.
Once this patch is in I'll set up automated HP-UX smoke testing next
week. FYI the smoke entry for HP-UX has some failed MANIFEST tests; one
is due to the image having been checked out from subve
tandard PMCs, so accessing the intval for the Integer PMC and its
decendents, floatval for Float PMC, stringval for String PMCs, etc) ?
Have a look at src/extend.c for the most abstract API.
You might also consider switching to branches/leo-ctx5. The new
calling conventions do auto-conversion betw
Leopold Toetsch wrote:
Klaas-Jan Stol wrote:
hi,
I'm currently trying to check out the NCI. As my Lua compiler only
uses PMCs (and not I/N/S registers), calling C functions will only be
done with PMCs.
I couldn't find info on this matter: suppose I have this string PMC,
Klaas-Jan Stol wrote:
hi,
I'm currently trying to check out the NCI. As my Lua compiler only uses
PMCs (and not I/N/S registers), calling C functions will only be done
with PMCs.
I couldn't find info on this matter: suppose I have this string PMC, how
can I access the actual st
1 - 100 of 306 matches
Mail list logo
