-glossary.pod
Log Message:
---
mention sink means void elsewhere
...It could also be taken as a subtle suggestion to write unit tests,
in which case you would discover such logical bugs within one
red/green/refactor iteration. ;-)
// Carl
On Sat, Jan 10, 2015 at 10:12 PM, Gabor Szabo wrote:
>
>
> On Sat, Jan 10, 2015 at 11:02 PM, Moritz Lenz wrote:
>>
>> To
On Sat, Jan 10, 2015 at 11:02 PM, Moritz Lenz wrote:
> To elaborate a bit on the previous answer:
>
> On 10.01.2015 17:12, Tobias Leich wrote:
>
>> In case we would know that certain methods had no side effects (and are
>> not called because of their side effects), ...
>>
>> But at the moment we
To elaborate a bit on the previous answer:
On 10.01.2015 17:12, Tobias Leich wrote:
In case we would know that certain methods had no side effects (and are
not called because of their side effects), ...
But at the moment we don't know and therefore we can't warn for every
method.
there are tw
$str.substr(/regex/, 'replaement)
>
> when I should write
>
> $str.=substr(/regex/, 'replaement)
>
>
> The former will *return* the replaced string to the void but not
> change it.
>
> I don't know if the above can be ever useful, but maybe this kind o
I keep writing code like this:
$str.substr(/regex/, 'replaement)
when I should write
$str.=substr(/regex/, 'replaement)
The former will *return* the replaced string to the void but not change it.
I don't know if the above can be ever useful, but maybe this kind of
constructs
# New Ticket Created by Paweł Pabian
# Please include the string: [perl #112492]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=112492 >
multidispatch.c:432: warning: request for implicit conversion from 'vo
ngs occur:
perl6lexinfo.c:121:1: warning: control may reach end of non-void function
[-Wreturn-type]
}
^
multidispatch.c:807:1: warning: control may reach end of non-void function
[-Wreturn-type]
}
^
# New Ticket Created by Aaron Sherman
# Please include the string: [perl #69552]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=69552 >
When .subst has a void or Bool context, it should issue a warning, since
there is
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #66252]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=66252 >
rakudo: my $x = "test"; given $x { say $_; m/(e.)/; say $/ }
rakudo c907d3: OUTPUT«
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #64514]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=64514 >
rakudo: =$*IN; say "FOO"
rakudo 0310a3: ( no output )
what's going on there?
masak:
On Sat Mar 14 03:57:46 2009, masak wrote:
> it seems that void-context prompt doesn't read a line, though.
> is that a bug or a feature?
> hmm
> if a feature, it seems not such a desirable one, by me.
> I mean, print already does that, and has a more apt name for
>
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #63864]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=63864 >
it seems that void-context prompt doesn't read a line, though.
I think use of "V" in your signature will allow you to do away with your
C code
grep for nci_vVi in
t/pmc/nci.t
and
src/nci_test.c
for an example.
Note that it used Pointer not UnmanagedStruct
Kevin
# New Ticket Created by Donald Hunter
# Please include the string: [perl #56828]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56828 >
Added support for void** params, i.e. for out parameters. This is
required
On Thu Jun 12 09:56:55 2008, nahoo wrote:
> > Does this suggest that the patch is moot, and that we may close the
> ticket?
>
> yes.
>
Since the patch seem to have been applied without this ticket being
updated, I'm marking it as resolved now.
> Does this suggest that the patch is moot, and that we may close the ticket?
yes.
Grepping for 'load_func' in src/dynext.c, I no longer see the line which
the OP was proposing to patch.
312:ARGIN_NULLOK(PMC *(*load_func)(PARROT_INTERP)),
317:if (load_func)
318:lib_pmc = (*load_func)(interp);
321:if (!load_func || !lib_pmc)
347:PMC *(*load_fun
On Tuesday 29 April 2008 21:28:18 Andy Dougherty wrote:
> If I have traced its lineage correctly, this patch fixes the following
> problem in sha256.c and sha512.c:
>
> "./sha256.pmc", line 164: void function cannot return value
>
> (note that line 164 of sh
in sha256.c and sha512.c:
"./sha256.pmc", line 164: void function cannot return value
(note that line 164 of sha256.pm is actually the "vim: ..." comment
at the end of the file. I'm not sure where the line numbers are
getting messed up.)
--- parrot-svn/config/gen/c
On Tue Jan 23 14:20:21 2007, particle wrote:
> when compiling src/pmc/pmethod.c, cl has a few warnings:
>
> src\pmc\pmethod_test.c
> D:/usr\local\parrot\bug\tools\build\../../lib\Parrot\Pmc2c\Utils.pm(1096)
> : warn
> ing C4102: 'test_method0_returns' : unreferenced label
> D:/usr\local\parrot\bug
In the old METHODs I'm converting on the pdd17pmc branch, a number of
them have a void return signature (now simply no return value), and use
void returns to bail out early on exceptional conditions. As in:
if (!foo)
return;
But, PCCMETHODs don't currently provide a way o
On Tue, 11 Sep 2007, Bernhard Schmalhofer via RT wrote:
> On Mo. 23. Jul. 2007, 10:35:38, doughera wrote:
> > As of version 0.4.14, parrot no longer builds for me with Sun's
> > Workshop
> > compiler on Solaris 8/SPARC. I get 66 errors of the form:
> >
> >
piler on Solaris 8/SPARC. I get 66 errors of the form:
"src/pmc/object.c", line 153: void function cannot return value
I tried browsing through the source history for lib/Parrot/Pmc2c
via the SVN web interface, but kept getting errors of the form:
An Exception Has Occurred
t; # http://rt.perl.org/rt3/Ticket/Display.html?id=42313 >
> >
> >
> > load_func is not a void pointer.
> >
> > Index: src/dynext.c
> > ===
> > --- src/dynext.c(revisio
Am Donnerstag, 5. April 2007 17:22 schrieb via RT:
> # New Ticket Created by
> # Please include the string: [perl #42313]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=42313 >
>
>
> load_fu
# New Ticket Created by
# Please include the string: [perl #42313]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42313 >
load_func is not a void pointer.
Index: src/dynex
On Thu, Mar 29, 2007 at 04:08:58PM -0700, chromatic wrote:
> On Thursday 29 March 2007 15:44, Steve Peters wrote:
>
> > On Thu, Mar 29, 2007 at 12:51:54PM -0700, Leopold Toetsch via RT wrote:
>
> > Sweeping dirt under the rug doesn't mean that the house has been cleaned
> > up. It means I've tur
On Thursday 29 March 2007 15:44, Steve Peters wrote:
> On Thu, Mar 29, 2007 at 12:51:54PM -0700, Leopold Toetsch via RT wrote:
> Sweeping dirt under the rug doesn't mean that the house has been cleaned
> up. It means I've turned it into someone else's problem. I'd rather
> Parrot was solid and
Am Freitag, 30. März 2007 00:44 schrieb Steve Peters:
> Sweeping dirt under the rug doesn't mean that the house has been cleaned
> up.
It's not related to hiding other possible errors. Some warnings are just not
appropriate to the usage of the very code, and there are a lot of them.
leo
On Thu, Mar 29, 2007 at 12:51:54PM -0700, Leopold Toetsch via RT wrote:
> Am Mittwoch, 28. März 2007 20:41 schrieb Nicholas Clark:
> > Getting parrot to build under -ansi -pedantic is left as an exercise to the
> > reader.
>
> By filtering other useless and/or nonsensical warnings - yes - else no.
On Wed, Mar 28, 2007 at 07:41:25PM +0100, Nicholas Clark wrote:
> On Tue, Mar 27, 2007 at 05:42:12AM -0700, Steve Peters via RT wrote:
>
> > > Anyway, it's worth noting that although one of functions actually
> > > doesn't
> > > return anything, it is documented as returning a PMC *. So either th
Am Mittwoch, 28. März 2007 20:41 schrieb Nicholas Clark:
> Getting parrot to build under -ansi -pedantic is left as an exercise to the
> reader.
By filtering other useless and/or nonsensical warnings - yes - else no.
leo - been there, done that
n is wrong in parrotobject.pmc and should
> > be
> > fixed.
>
> Unfortunately, I can't find a gcc warning flag that would seem to catch this
> sort of situation
> either.
$ gcc -ansi -pedantic -Wall -o void void.c
void.c: In function `uggh':
void.c:9: warning: `ret
On Tuesday 27 March 2007 11:32, chromatic wrote:
> On Monday 26 March 2007 20:55, Steve Peters wrote:
> > A couple of functions in XX are trying to return values from void
> > functions. To some compilers, such as the standard HP-UX compilers, this
> > is a big no-no. The p
On Monday 26 March 2007 20:55, Steve Peters wrote:
> A couple of functions in XX are trying to return values from void
> functions. To some compilers, such as the standard HP-UX compilers, this is
> a big no-no. The patch below fixes this problem.
Thanks, applied as r17791.
-- c
http://rt.perl.org/rt3/Ticket/Display.html?id=42110 >
> >
> >
> > A couple of functions in XX are trying to return values from void
> functions.
> > To some compilers, such as the standard HP-UX compilers, this is a
> big
> > no-no. The patch below fixes this problem.
e of functions in XX are trying to return values from void functions.
> To some compilers, such as the standard HP-UX compilers, this is a big
> no-no. The patch below fixes this problem.
Yes. I sent in this same patch last week. I didn't send it to RT since I
thought it was so
# New Ticket Created by Steve Peters
# Please include the string: [perl #42110]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42110 >
A couple of functions in XX are trying to return values from void functions.
To s
Void functions can't try to return anything. I haven't checked if this
patch is "right" or not. The documentation for Parrot_set_attrib_by_num()
claims it returns a PMC *, but the source code uses 'void' and doesn't
actually return anything. I don't k
chromatic wrote:
Jim, can you resend with diffs in unified format? (That's "diff -u",
not "diff".) They're much, much easier to read.
-- c
I screwed up. I attached this to the wrong ticket.
Jim, can you resend with diffs in unified format? (That's "diff -u",
not "diff".) They're much, much easier to read.
-- c
On Tue Jan 23 14:20:21 2007, particle wrote:
> when compiling src/pmc/pmethod.c, cl has a few warnings:
>
> src\pmc\pmethod_test.c
> D:/usr\local\parrot\bug\tools\build\../../lib\Parrot\Pmc2c\Utils.pm(1096)
> : warn
> ing C4102: 'test_method0_returns' : unreferenced label
> [snip]
> it seems the p
# New Ticket Created by Jerry Gay
# Please include the string: [perl #41328]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41328 >
when compiling src/pmc/pmethod.c, cl has a few warnings:
src\pmc\pmethod_test.c
D:/usr\loc
On Wed Dec 20 14:21:52 2006, coke wrote:
> Whatever you were able to apply is fine.
Applied in 16211, thanks!
Whatever you were able to apply is fine.
On Dec 20, 2006, at 10:35 AM, Paul Cochrane via RT wrote:
On Tue Aug 29 19:03:44 2006, coke wrote:
The attached patch casts all the printfs arguments corresponding to
"%
p" to be (void *), to avoid compiler warnings.
However, the follo
On Tue Aug 29 19:03:44 2006, coke wrote:
> The attached patch casts all the printfs arguments corresponding to
"%
> p" to be (void *), to avoid compiler warnings.
>
> However, the following tests fail after the change:
>
> Failed Test Stat Wstat Total
06 at 07:03:44PM -0700, Will Coleda wrote:
> >># New Ticket Created by Will Coleda
> >># Please include the string: [perl #40253]
> >># in the subject line of all future correspondence about this issue.
> >># http://rt.perl.org/rt3/Ticket/Display.html?id=40253 >
l?id=40253 >
The attached patch casts all the printfs arguments corresponding
to "%
p" to be (void *), to avoid compiler warnings.
However, the following tests fail after the change:
Failed Test Stat Wstat Total Fail
g/rt3/Ticket/Display.html?id=40253 >
>
>
> The attached patch casts all the printfs arguments corresponding to "%
> p" to be (void *), to avoid compiler warnings.
>
> However, the following tests fail after the change:
>
> Failed Test
# New Ticket Created by Will Coleda
# Please include the string: [perl #40253]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40253 >
The attached patch casts all the printfs arguments corresponding to "%
p"
# New Ticket Created by Will Coleda
# Please include the string: [perl #37405]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37405 >
Currently when invoking a .Sub in PIR with no return values, you must
write:
function
HaloO Autrijus,
you wrote:
On Fri, May 13, 2005 at 07:13:53PM +0200, "TSa (Thomas Sandlaß)" wrote:
Larry Wall wrote:
: Void context still exists and is not a form of singular or plural
: context. Perhaps this should be called nullar context, although void
: context works equally well for
Autrijus Tang wrote:
On Fri, May 13, 2005 at 07:13:53PM +0200, "TSa (Thomas Sandlaß)" wrote:
Larry Wall wrote:
: Void context still exists and is not a form of singular or plural
: context. Perhaps this should be called nullar context, although void
: context works equally well
On Fri, May 13, 2005 at 07:13:53PM +0200, "TSa (Thomas SandlaÃ)" wrote:
> Larry Wall wrote:
> >: Void context still exists and is not a form of singular or plural
> >: context. Perhaps this should be called nullar context, although void
> >: context works equally w
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> In classes/float.pmc, the MMD_DEFAULT branch of i_subtract tries to
> return a value, even though the function is defined as 'void'.
Thanks, applied.
leo
lue, even though the function is defined as 'void'.
I haven't worked my way through the pmc generation stuff to be certain
this is the right patch, but it will at least compile.
--- parrot-current/classes/float.pmcMon Apr 18 11:22:52 2005
+++ parrot-andy/classes/float.pmc W
Sun's cc compiler complains about dynclasses/matchrange.pmc:
"matchrange.pmc", line 305: void function cannot return value
The following patch fixes it.
--- parrot-current/dynclasses/matchrange.pmcFri Sep 17 00:55:02 2004
+++ parrot-andy/dynclasses/matchrange.pmc Mon
Andy Dougherty wrote:
The Solaris compiler complained when classes/complex.c tried to return a
value from a void function. This patch assumes the function indeed is
intended to be void and no return value is needed.
You're right, it slipped.
We really need compiler flags to catch these.
Stil
Andy Dougherty (via RT) wrote:
The Solaris compiler complained when classes/complex.c tried to return a
value from a void function. This patch assumes the function indeed is
intended to be void and no return value is needed.
Thanks, applied.
leo
lue from a void function. This patch assumes the function indeed is
intended to be void and no return value is needed.
--- parrot-current/classes/complex.pmc Thu Jul 1 04:47:13 2004
+++ parrot-andy/classes/complex.pmc Thu Jul 1 14:22:39 2004
@@ -433,7 +433,7 @@
void set_number_keyed (
urn 0 from a void function. The
problem is that the $retval was being matched against /void /, but the
trailing space had already been stripped off.
Applied this fix last night, thanks.
-Melvin
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #24341]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=24341 >
The new classes/null.pl was trying to return 0 from a void function. The
problem
At 04:57 PM 11/23/2001 +0100, Bart Lateur wrote:
>On Wed, 21 Nov 2001 13:46:09 -0500, Dan Sugalski wrote:
>
> >Nah, using an I register as a host-machine-address for jumps doesn't argue
> >for sizeof(INTVAL) >= sizeof(void *). Instead, it argues that the design
> >
On Wed, 21 Nov 2001 13:46:09 -0500, Dan Sugalski wrote:
>Nah, using an I register as a host-machine-address for jumps doesn't argue
>for sizeof(INTVAL) >= sizeof(void *). Instead, it argues that the design
>that uses an int as an absolute address is wrong.
>
>I'm g
At 11:35 AM 11/21/2001 -0800, Brent Dax wrote:
>Dan Sugalski:
># At 08:43 PM 11/19/2001 -0500, brian wheeler wrote:
># >On Mon, 2001-11-19 at 19:59, James Mastros wrote:
># > > I propose that we make INTVAL and opcode_t the same size,
># and gaurrenteed
># &g
On Wed, 21 Nov 2001, Dan Sugalski wrote:
> Nah, using an I register as a host-machine-address for jumps doesn't argue
> for sizeof(INTVAL) >= sizeof(void *). Instead, it argues that the design
> that uses an int as an absolute address is wrong.
>
> I'm going to rew
Dan Sugalski:
# At 08:43 PM 11/19/2001 -0500, brian wheeler wrote:
# >On Mon, 2001-11-19 at 19:59, James Mastros wrote:
# > > I propose that we make INTVAL and opcode_t the same size,
# and gaurrenteed
# > > to be able to hold a void*.
# > >
# >
# >Seems reasonable to
At 12:19 PM 11/20/2001 -0500, Ken Fox wrote:
>James Mastros wrote:
> > In byteswapping the bytecode ...
> >
> > I propose that we make INTVAL and opcode_t the same size, and gaurrenteed
> > to be able to hold a void*.
>
>It sounds like you want portable byte co
At 08:43 PM 11/19/2001 -0500, brian wheeler wrote:
>On Mon, 2001-11-19 at 19:59, James Mastros wrote:
> > I propose that we make INTVAL and opcode_t the same size, and gaurrenteed
> > to be able to hold a void*.
> >
>
>Seems reasonable to me, since jsr and jump are slat
> On Tue, 20 Nov 2001, Ken Fox wrote:
> > It sounds like you want portable byte code. Is that a goal?
> I do indeed want portable packfiles, and I thought that was more then a
> "goal", I thought that was a "requirement". In an ideal world, I want a
> PVM to be intergrated in a webbrowser the sam
On Tue, 20 Nov 2001, Ken Fox wrote:
> It sounds like you want portable byte code. Is that a goal?
I do indeed want portable packfiles, and I thought that was more then a
"goal", I thought that was a "requirement". In an ideal world, I want a
PVM to be intergrated in a webbrowser the same way a JV
On Tue, 2001-11-20 at 12:19, Ken Fox wrote:
> James Mastros wrote:
> > In byteswapping the bytecode ...
> >
> > I propose that we make INTVAL and opcode_t the same size, and gaurrenteed
> > to be able to hold a void*.
>
> It sounds like you want portable byte co
James Mastros wrote:
> In byteswapping the bytecode ...
>
> I propose that we make INTVAL and opcode_t the same size, and gaurrenteed
> to be able to hold a void*.
It sounds like you want portable byte code. Is that a goal? It seems like
we can have either mmap'able byte code
feature-splitting, for example in file opening, some interfaces
> (POSIX open(), for example) want to return an integer (the fd), and some
> (win32 CreateFile(), for example) want to return a void* (the file
> handle). (This is a pointer to a kernel-allocated structure that will
> cause a s
r (the fd), and some
(win32 CreateFile(), for example) want to return a void* (the file
handle). (This is a pointer to a kernel-allocated structure that will
cause a segfault to directly access, BTW, so no GC problems here.)
I propose that we make INTVAL and opcode_t the same size, and gaurrenteed
to
Segher Boessenkool wrote:
> > Are there any cases where a void * cannot be placed into an integer
> > register? It seems like it shouldn't happen, especially since jump and
> > jsr are supposed to take an integer register and they point to a
> > host-machine-addres
On Mon, 2001-11-19 at 12:43, Hong Zhang wrote:
> > Are there any cases where a void * cannot be placed into an integer
> > register? It seems like it shouldn't happen, especially since jump and
> > jsr are supposed to take an integer register and they point to a
&
> Are there any cases where a void * cannot be placed into an integer
> register? It seems like it shouldn't happen, especially since jump and
> jsr are supposed to take an integer register and they point to a
> host-machine-address...
What register are you talking about? The
brian wheeler wrote:
>
> Are there any cases where a void * cannot be placed into an integer
> register? It seems like it shouldn't happen, especially since jump and
> jsr are supposed to take an integer register and they point to a
> host-machine-address...
>
>
Are there any cases where a void * cannot be placed into an integer
register? It seems like it shouldn't happen, especially since jump and
jsr are supposed to take an integer register and they point to a
host-machine-address...
Brian
Quoting Dan Sugalski <[EMAIL PROTECTED]>:
> > Could you explain again why you don't want char* anywhere, and
> prefer
> > void*?
>
> Because for character data we're not sure char * is right. (Might be
> wchar_t, __int16, __int32, or something else) I
On Thu, Sep 20, 2001 at 04:25:45PM -0400, Dan Sugalski wrote:
> At 01:06 PM 9/20/2001 -0700, Robert Spier wrote:
> > Could you explain again why you don't want char* anywhere, and prefer
> > void*?
>
> Because for character data we're not sure char * is right
At 01:06 PM 9/20/2001 -0700, Robert Spier wrote:
>Dan,
>
> Could you explain again why you don't want char* anywhere, and prefer
> void*?
Because for character data we're not sure char * is right. (Might be
wchar_t, __int16, __int32, or something else) It's also
Dan,
Could you explain again why you don't want char* anywhere, and prefer void*?
You answered this on language-dev, but went off on what seemed to be a tangent
about encodings.
Some ramblings of my own that may be confusing me, are:
char* doesn't necessarily mean "a st
At 10:04 AM 9/13/2001 +0100, Tom Hughes wrote:
>This patch fixes a couple of cases where arithmetic on void * pointers
>is being done, which isn't valid although gcc seems to allow it.
I need to get this building on Dec C again, I see. Damn.
>Of course the memory.c code is broken
This patch fixes a couple of cases where arithmetic on void * pointers
is being done, which isn't valid although gcc seems to allow it.
Of course the memory.c code is broken anyway because it assumes a
pointer will fit in an IV and I'm not sure that will always be true
will it? Anyway
87 matches
Mail list logo
