[Issue 3409] New: stdio.File.seek() doesn't work for files 2GB

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3409

   Summary: stdio.File.seek() doesn't work for files 2GB
   Product: D
   Version: 2.035
  Platform: Other
OS/Version: Windows
Status: NEW
  Keywords: patch
  Severity: major
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com


--- Comment #0 from David Simcha dsim...@yahoo.com 2009-10-16 23:01:40 PDT ---
stdio.File.seek() doesn't work for large files.  This is because fseek() is
using an int to represent the offset because it's crufty old C code from the
Stone Age.  Instead, it throws a ConvOverflowError exception on trying to seek
a long distance ( int.max).  The proper fix would be to use the C function
that takes a long instead, but this is apparently not available on all
platforms and not part of the C standard.  

I've attached a file with an implementation of a kludge to work around this
issue by seeking incrementally.  It's ugly but it works.  It's implemented in
terms of the current seek() implementation, and I haven't integrated it into
the File struct, but the basic code is there.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3410] New: std.stdio.File.tell() doesn't work for files 2GB

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3410

   Summary: std.stdio.File.tell() doesn't work for files 2GB
   Product: D
   Version: 2.035
  Platform: Other
OS/Version: Windows
Status: NEW
  Severity: major
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com


--- Comment #0 from David Simcha dsim...@yahoo.com 2009-10-16 23:05:15 PDT ---
THe C function returns an int, which wraps around to negative values for files
2GB, and the result of File.tell() is some absurd number that you get when you
cast this value to a ulong, I think.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3409] stdio.File.seek() doesn't work for files 2GB

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3409



--- Comment #1 from David Simcha dsim...@yahoo.com 2009-10-16 23:18:26 PDT ---
Oops, looks like I forgot to attach the attachment.  That's ok, on further
testing, it only solved the problem up to 4GB anyhow.  I guess what *really*
needs to happen is LFS support.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3409] stdio.File.seek() doesn't work for files 2GB

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3409


David Simcha dsim...@yahoo.com changed:

   What|Removed |Added

   Keywords|patch   |


--- Comment #2 from David Simcha dsim...@yahoo.com 2009-10-17 08:45:01 PDT ---
Note that std.stream gets this right on Win32 but not Linux by using the Win32
API directly.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3410] std.stdio.File.tell() doesn't work for files 2GB

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3410



--- Comment #1 from David Simcha dsim...@yahoo.com 2009-10-17 08:45:24 PDT ---
Note that std.stream gets this right on Win32 but not Linux by using the Win32
API directly.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3409] stdio.File.seek() doesn't work for files 2GB

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3409


Andrei Alexandrescu and...@metalanguage.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||and...@metalanguage.com
 AssignedTo|nob...@puremagic.com|and...@metalanguage.com


--- Comment #3 from Andrei Alexandrescu and...@metalanguage.com 2009-10-17 
09:00:27 PDT ---
The bug is in druntime. It defines fseek and ftell in core.stdc.stdio like
this:

intfseek(FILE* stream, long offset, int whence);
c_long ftell(FILE* stream);

And it defines c_long in core.stdc.config like this:


version( Windows )
{
alias int   c_long;
alias uint  c_ulong;
}
else
{
  static if( (void*).sizeof  int.sizeof )
  {
alias long  c_long;
alias ulong c_ulong;
  }
  else
  {
alias int   c_long;
alias uint  c_ulong;
  }
} 

I don't know why under Windows c_long is actually 32 bit.

Then, in my code I had this note:

void seek(long offset, int origin = SEEK_SET)
{
enforce(p  p.handle,
Attempting to seek() in an unopened file);
// @@@ Dubious: why is fseek in std.c.stdio taking an int???
errnoEnforce(core.stdc.stdio.fseek(
p.handle, to!int(offset), origin) == 0,
Could not seek in file `~p.name~');
}

So it seeme like there was something fishy going on.

I emailed Sean about the problem. He needs to fix druntime, then I will fix
stdio, and then we can close this.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3410] std.stdio.File.tell() doesn't work for files 2GB

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3410


Andrei Alexandrescu and...@metalanguage.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||and...@metalanguage.com
 AssignedTo|nob...@puremagic.com|and...@metalanguage.com


--- Comment #2 from Andrei Alexandrescu and...@metalanguage.com 2009-10-17 
09:01:22 PDT ---
(In reply to comment #1)
 Note that std.stream gets this right on Win32 but not Linux by using the Win32
 API directly.

Casting won't help much, we need the long.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3409] stdio.File.seek() doesn't work for files 2GB

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3409



--- Comment #4 from David Simcha dsim...@yahoo.com 2009-10-17 09:41:44 PDT ---
Could be wrong, but I think the way druntime defines these functions is because
that's the way they're defined in the C std lib API.  I think to do better you
need to use OS-specific APIs directly.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3411] New: DMD 1.x svn branch doesn't compile

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3411

   Summary: DMD 1.x svn branch doesn't compile
   Product: D
   Version: 1.051
  Platform: All
OS/Version: Linux
Status: NEW
  Keywords: patch
  Severity: regression
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: llu...@gmail.com


--- Comment #0 from Leandro Lucarella llu...@gmail.com 2009-10-17 10:43:35 
PDT ---
Created an attachment (id=475)
Patch against DMD 1.x branch r215

The header mars.h is looked for in a non existent directory named mars.

Attached is a patch that fixes the include to use the mars.h header in the base
directory.

You can apply the patch using:
$ patch -p2  0001-Use-the-right-path-for-mars.h.patch
in the src directory.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3412] New: DMD 1.x svn branch store string literal in mutable char*

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3412

   Summary: DMD 1.x svn branch store string literal in mutable
char*
   Product: D
   Version: 1.051
  Platform: All
OS/Version: All
Status: NEW
  Keywords: patch
  Severity: trivial
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: llu...@gmail.com


--- Comment #0 from Leandro Lucarella llu...@gmail.com 2009-10-17 10:46:49 
PDT ---
Created an attachment (id=476)
Patch against DMD 1.x branch r215

String literals are supposed to be const char* instead of mutable char*, but
DMD uses char* in a few places.

Attached is a patch that stores the string literals using the right type.

As a side effect, it avoids some compiler warnings (at least with GCC).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3413] New: DMD makefiles needs improvements

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3413

   Summary: DMD makefiles needs improvements
   Product: D
   Version: 1.051
  Platform: All
OS/Version: Linux
Status: NEW
  Keywords: patch
  Severity: enhancement
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: llu...@gmail.com


--- Comment #0 from Leandro Lucarella llu...@gmail.com 2009-10-17 11:47:54 
PDT ---
Created an attachment (id=477)
Patch against DMD 1.x branch r215 for adding dependency handling to linux.mak

The DMD make-based build system has a few problems. The main problems I see
are:

1) Lack of dependency handling
2) Excessive duplication

1) Is bad because you have to do a 'make clean all' each time you change
something to be sure that the compiled binary wont have problems. This is
really easy to fix, see the attached file which implement this for the Linux
makefile (but can be applied to any makefile using GCC).

2) Is bad because is really hard to write, read and maintain, and very error
prone (for instance, r215 is missing the new json.{h,c,o} files in the
solaris.mak file). The ideal would be to have a makefile with the common stuff
and other specific makefiles with the specifics for each OS.

I can redesign the DMD makefiles to support automatic dependency handling and
to be highly readable and simple to maintain, if there are any interest in
this. I will only need some assistance for testing it in other OSs than Linux
because I don't have them installed.

I'm attaching just a teaser patch that fixes 1) for Linux as a prove of
concept, I didn't wanted to spend time redesigning the DMD build system because
I have the feeling that maybe is not something that Walter wants.

You can apply the patch with patch -p2  0001-WIP-Improve-build-system.patch in
the src directory.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3412] DMD 1.x svn branch store string literal in mutable char*

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3412



--- Comment #1 from Leandro Lucarella llu...@gmail.com 2009-10-17 11:49:06 
PDT ---
I forgot to mention that you can apply the patch with:
patch -p2  0002-Store-string-literals-in-const-char-variables.patch
in the src directory

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3414] New: std.file.listdir: Use regex, not RegExp

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3414

   Summary: std.file.listdir:  Use regex, not RegExp
   Product: D
   Version: 2.035
  Platform: Other
OS/Version: Windows
Status: NEW
  Keywords: patch
  Severity: normal
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com


--- Comment #0 from David Simcha dsim...@yahoo.com 2009-10-17 14:42:45 PDT ---
std.file.listdir still uses the old-school std.regexp lib, even though this
will likely be deprecated soon.  Here's a version using the new-school
std.regex.

string[] listdir(Char)(in char[] pathname, Regex!(Char) r)
{
Appender!(string[]) result;

bool callback(DirEntry* de)
{
if (de.isdir)
listdir(de.name, callback);
else
{
if (!match(de.name, r).empty)
result.put(de.name);
}
return true; // continue
}

listdir(pathname, callback);
return result.data;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3414] std.file.listdir: Use regex, not RegExp

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3414


Andrei Alexandrescu and...@metalanguage.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||and...@metalanguage.com
 AssignedTo|nob...@puremagic.com|and...@metalanguage.com


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3415] New: JSON output does not pass validation

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3415

   Summary: JSON output does not pass validation
   Product: D
   Version: 1.050
  Platform: x86_64
OS/Version: Linux
Status: NEW
  Severity: minor
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: brian-sch...@cox.net


--- Comment #0 from brian-sch...@cox.net 2009-10-17 15:16:41 PDT ---
Items in arrays output by the -X option of dmd are not properly separated by
commas. The most common example of this is class member functions.

Example:

...
members : [
{
name : drawLayer,
kind : function,
type : void(uint layer, int x, int y),
line : 133}
{
name : drawAllLayers,
kind : function,
type : void(int x, int y),
line : 149}
...

Should read:

...
members : [
{
name : drawLayer,
kind : function,
type : void(uint layer, int x, int y),
line : 133},
{
name : drawAllLayers,
kind : function,
type : void(int x, int y),
line : 149},
...

The lack of commas causes the resulting files to fail validation and attempts
at parsing. See: http://www.jsonlint.com/

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3391] gdb: dynamic arrays and associative arrays are not properly printed

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3391



--- Comment #2 from Leandro Lucarella llu...@gmail.com 2009-10-17 18:01:47 
PDT ---
Created an attachment (id=478)
objdump -W for DMD

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3391] gdb: dynamic arrays and associative arrays are not properly printed

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3391



--- Comment #1 from Leandro Lucarella llu...@gmail.com 2009-10-17 18:00:47 
PDT ---
Maybe this is useful.

For this file:
$ cat -n dbg.d
 1
 2void dummy_function()
 3{
 4char[][] str_array;
 5str_array ~= hello;
 6str_array ~= world;
 7int[2] int_sarray;
 8int_sarray[0] = 1;
 9int_sarray[1] = -1;
10}
11

DMD (svn 1.x branch at r215) generates this:
 16c: Abbrev Number: 5 (DW_TAG_array_type)
6d   DW_AT_sibling : 0x7f
71   DW_AT_type: 0x65

While LDC generates:
 286: Abbrev Number: 3 (DW_TAG_variable)
87   DW_AT_name: str_array
91   DW_AT_decl_file   : 1
92   DW_AT_decl_line   : 4
93   DW_AT_type: 0x121  
97   DW_AT_location: 2 byte block: 75 70  (DW_OP_breg5: -16)

I will attach the full dump of objdump -W for both DMD and LDC.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3391] gdb: dynamic arrays and associative arrays are not properly printed

2009-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3391



--- Comment #3 from Leandro Lucarella llu...@gmail.com 2009-10-17 18:02:23 
PDT ---
Created an attachment (id=479)
objdump -W for LDC

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---