{5} Assigned, Active Tickets by Owner (Full Description) (90 matches)

$ make -f linux.mak console/hello
Building :  console/hello
bud console/hello.d -noautoimport -op -clean -full -g -debug -I.. -Tconsole/hello -unittest
/usr/local/lib/gcc/powerpc-unknown-linux-gnu/4.1.1/../../../libgphobos.a(Thread.o): In function `_D5tango4core6Thread5Fiber9switchOutMFZv':
Thread.d:(.text+0xb18): referencia a `fiber_switchContext' sin definir
/usr/local/lib/gcc/powerpc-unknown-linux-gnu/4.1.1/../../../libgphobos.a(Thread.o): In function `_D5tango4core6Thread5Fiber8switchInMFZv':
Thread.d:(.text+0xbb4): referencia a `fiber_switchContext' sin definir
/usr/local/lib/gcc/powerpc-unknown-linux-gnu/4.1.1/../../../libgphobos.a(Thread.o): In function `_D5tango4core6Thread5Fiber4callMFbZv':
Thread.d:(.text+0x13f0): referencia a `fiber_switchContext' sin definir
/usr/local/lib/gcc/powerpc-unknown-linux-gnu/4.1.1/../../../libgphobos.a(Thread.o): In function `fiber_entryPoint':
Thread.d:(.text+0x238c): referencia a `fiber_switchContext' sin definir
/usr/local/lib/gcc/powerpc-unknown-linux-gnu/4.1.1/../../../libgphobos.a(Thread.o): In function `_D5tango4core6Thread5Fiber13yieldAndThrowFC6ObjectZv':
Thread.d:(.text+0x2478): referencia a `fiber_switchContext' sin definir
/usr/local/lib/gcc/powerpc-unknown-linux-gnu/4.1.1/../../../libgphobos.a(Thread.o):Thread.d:(.text+0x2528): más referencias a `fiber_switchContext' sin definir a continuación

These are old and somewhat outdated (I fixed at least parts of the first):

• TopicBuildingAndCompiling
• WindowsInstall
• DMDWin32Problems

It's also final. This makes me sad.

For the case of non-blocking sockets, the eof case is common. I could see it throwing an error if the connection goes bad (currently the only cause for Eof in blocking sockets) If my proposal in http://www.dsource.org/projects/tango/ticket/279 gets accepted, buffer.drain could check both return values, throw an error only on the case of a bad connection, and return 0 in the case of Eof.

From http://digitalmars.com/d/1.0/operatoroverloading.html
The assignment operator cannot be overloaded for rvalues that can be implicitly cast to the lvalue type.

Doing so results in a compiler error. But doing it via an alias, as done in tango.io.FilePath?, the compiler does not complain.

But trying to nullify a ref result in compile error:

auto fp = new FilePath( "/tmp" );
fp = null;

t.d(14): Error: overloads FilePath(FilePath path) and FilePath(char[] path) both match argument list for set
t.d(14): function tango.io.FilePath.FilePath.set called with argument types:
        (void*)
matches both:
        tango.io.FilePath.FilePath.set(FilePath)
and:
        tango.io.FilePath.FilePath.set(char[])

My specific instance: IBuffer.read(delegate) expects an uint-returning delegate instead of a size_t-returning delegate, while the latter seems more natural. This means that on my amd64-gdc

buffer.read( (void[] slice) { return slice.length; } );

doesn't compile, it currently needs to be

buffer.read( delegate uint(void[] slice) { return slice.length; } );

I asked about this on #d.tango and Sean answered:

<sean_k> the IO code uses uint to represent buffer length. you'll have to ask Kris about why. <sean_k> my guess is that it will have to change at some point

Utf.d

warning - tango/text/convert/Utf.d:85: Error: implicit conversion of expression (input.length) of type ulong to uint can cause loss of data
warning - tango/text/convert/Utf.d:89: Error: implicit conversion of expression ((input.length) * 2LU + 3LU) of type ulong to int can cause loss of data
warning - tango/text/convert/Utf.d:110: Error: implicit conversion of expression ((pOut - cast(char*)output) / 1L) of type long to int can cause loss of data
warning - tango/text/convert/Utf.d:139: Error: implicit conversion of expression ((pOut - cast(char*)output) / 1L) of type long to ulong can cause loss of data
warning - tango/text/convert/Utf.d:205: Error: implicit conversion of expression ((pIn - cast(char*)input) / 1L) of type long to ulong can cause loss of data
warning - tango/text/convert/Utf.d:213: Error: implicit conversion of expression ((pIn - cast(char*)input) / 1L) of type long to uint can cause loss of data
warning - tango/text/convert/Utf.d:217: Error: implicit conversion of expression ((pIn - cast(char*)input) / 1L) of type long to ulong can cause loss of data
warning - tango/text/convert/Utf.d:243: Error: implicit conversion of expression (input.length) of type ulong to uint can cause loss of data
warning - tango/text/convert/Utf.d:247: Error: implicit conversion of expression ((input.length) * 2LU + 4LU) of type ulong to int can cause loss of data
warning - tango/text/convert/Utf.d:268: Error: implicit conversion of expression ((pOut - cast(char*)output) / 1L) of type long to int can cause loss of data
warning - tango/text/convert/Utf.d:305: Error: implicit conversion of expression ((pOut - cast(char*)output) / 1L) of type long to ulong can cause loss of data
warning - tango/text/convert/Utf.d:362: Error: implicit conversion of expression ((pIn - cast(char*)input) / 1L) of type long to ulong can cause loss of data
warning - tango/text/convert/Utf.d:380: Error: implicit conversion of expression ((pIn - cast(char*)input) / 1L) of type long to ulong can cause loss of data
warning - tango/text/convert/Utf.d:388: Error: implicit conversion of expression ((pIn - cast(char*)input) / 1L) of type long to uint can cause loss of data
warning - tango/text/convert/Utf.d:392: Error: implicit conversion of expression ((pIn - cast(char*)input) / 1L) of type long to ulong can cause loss of data
warning - tango/text/convert/Utf.d:416: Error: implicit conversion of expression (input.length) of type ulong to uint can cause loss of data
warning - tango/text/convert/Utf.d:419: Error: implicit conversion of expression ((input.length) * 2LU + 2LU) of type ulong to int can cause loss of data
warning - tango/text/convert/Utf.d:440: Error: implicit conversion of expression ((pOut - cast(wchar*)output) / 2L) of type long to int can cause loss of data
warning - tango/text/convert/Utf.d:460: Error: implicit conversion of expression ((pOut - cast(wchar*)output) / 2L) of type long to ulong can cause loss of data
warning - tango/text/convert/Utf.d:499: Error: implicit conversion of expression ((pIn - cast(wchar*)input) / 2L) of type long to ulong can cause loss of data
warning - tango/text/convert/Utf.d:514: Error: implicit conversion of expression ((pIn - cast(wchar*)input) / 2L) of type long to ulong can cause loss of data
warning - tango/text/convert/Utf.d:522: Error: implicit conversion of expression ((pIn - cast(wchar*)input) / 2L) of type long to uint can cause loss of data
warning - tango/text/convert/Utf.d:526: Error: implicit conversion of expression ((pIn - cast(wchar*)input) / 2L) of type long to ulong can cause loss of data

/**

tango.sys.win32.UserGdi? int SHFileOperation(LPSHFILEOPSTRUCT) should be:

*/

    int SHFileOperationA(LPSHFILEOPSTRUCTA);
    int SHFileOperationW(LPSHFILEOPSTRUCTW);

//tango.sys.win32.Types SHFILEOPSTRUCT shouled be:

struct SHFILEOPSTRUCTA {
	HWND         hwnd;
	UINT         wFunc;
	LPCSTR       pFrom;
	LPCSTR       pTo;
	FILEOP_FLAGS fFlags;
	BOOL         fAnyOperationsAborted;
	PVOID        hNameMappings;
	LPCSTR       lpszProgressTitle;
}
alias SHFILEOPSTRUCTA* LPSHFILEOPSTRUCTA;

struct SHFILEOPSTRUCTW {
	HWND         hwnd;
	UINT         wFunc;
	LPCWSTR      pFrom;
	LPCWSTR      pTo;
	FILEOP_FLAGS fFlags;
	BOOL         fAnyOperationsAborted;
	PVOID        hNameMappings;
	LPCWSTR      lpszProgressTitle;
}
alias SHFILEOPSTRUCTW* LPSHFILEOPSTRUCTW;

and add these to Types.di, for use with SHFileOperation

/** lacks in Tango 
 See_Also:
    SHFILEOPSTRUCT http://msdn2.microsoft.com/en-us/library/bb759795(VS.85).aspx
    SHFileOperation http://msdn2.microsoft.com/en-us/library/bb762164(VS.85).aspx
*/
const FILEOP_FLAGS
	FOF_MULTIDESTFILES        = 0x0001,
	FOF_CONFIRMMOUSE          = 0x0002,
	FOF_SILENT                = 0x0004,
	FOF_RENAMEONCOLLISION     = 0x0008,
	FOF_NOCONFIRMATION        = 0x0010,
	FOF_WANTMAPPINGHANDLE     = 0x0020,
	FOF_ALLOWUNDO             = 0x0040,
	FOF_FILESONLY             = 0x0080,
	FOF_SIMPLEPROGRESS        = 0x0100,
	FOF_NOCONFIRMMKDIR        = 0x0200,
	FOF_NOERRORUI             = 0x0400,
	FOF_NOCOPYSECURITYATTRIBS = 0x0800;

enum : UINT {
	FO_MOVE = 1,
	FO_COPY,
	FO_DELETE,
	FO_RENAME
}

If you could get the iterator from the end of a container like a list, you could use the list as a queue. If the container was a map, you could keep discarding the largest element, to keep a map of the N smallest items of a set.

tango.io.Print's print,format, and formatln should all come in 'va' versions that take a _argptr,_arguments pair.

I would like to propose the following change in update method:

instead of current:

    r &= 0xFFFFFF00;
    r /= 0x100;
    r &= 16777215;

change it to:

    r >>>= 8;

this should improve speed of calculating crc a bit.

similiar code is also present in ctor, but it's short loop, and usually called much less times than update, but readability could be imporved:

current:

        if (value & 1) {
                value &= 0xFFFFFFFE;
                value /= 2;
                value &= 0x7FFFFFFF;
                value ^= polynomial;
        }
        else
        {
                value &= 0xFFFFFFFE;
                value /= 2;
                value &= 0x7FFFFFFF;
        }

to:

        if (value & 1)
                value >>>=1, value ^= polynomial;
        else
                value >>>=1;

If there are any reasons for keeping & + /= + & instead of >>> please write them below.

Testing on 350M file on my computer gives avarage times 6.55 secs for old version and 5.65 secs for new one that gives about 16% speed-up.

Attached is a UTF conversion testing module and its output when used with Tango's tango.text.convert.Utf functions. What Tango fails at is that it's too liberal in what it accepts. To name a few: UTF-16 surrogates encoded in UTF-8 or UTF-32, overlong representations, UTF-8 continuation bytes that aren't part of a whole sequence.

The forum topic http://www.dsource.org/projects/tango/forums/topic/13 has a UTF-8 to UTF-32 converter which works for a single code point, returning a dchar. Fixing the toUtf32 functions, at least, should be trivial if it is used as a helper function. The toUtf16 ones I haven't looked at too much, but shouldn't be too difficult.

public T[] tango.text.convert.Layout.Layout(T).convertOne(T[] result, TypeInfo? ti, Arg arg)

If convertOne is meant to be a public function, should it not take result as the last argument instead of as the first one and make result default to null like other similar Tango funcs?

Hex output & parsing required in tango.text.convert

I would like to have a summary about the existing protocols.

What to use, to write/read network byte order?

• EndianProtocol?: switches the byte order
• NativeProtocol?: Explicitely writes in the byte order of the machine
• PickleProtocol?: writes/reads in network byte order?

What about, to use a "better" name for PickleProtocol?? e.g. "NetworkByteorderProtocol?" or "BigEndianProtocol?"

the "read" functionality works really well, sets the hadTimeout etc, but connecting and writing does not seem to work as well.

Enables applications to use a serial port (aka COM-port, ttyS). Usage is similar to that of FileConduit?:

auto serPort = new SerialPort("ttyS0");
serPort.speed = 38400;
serPort.write("Hello world!");
serPort.close();

2 cases:

1. stopping on first non option (i.e. ssh -v host -v ls -la: this should stop after the second -v)
2. stopping when a sentinel option is encountered (i.e. '--' by itself)

AKA "The Great const Cleanup".

Is this going to happen any time soon? I suppose you'll be waiting for D 2.0 to stabilize, first? Or will there be a fork of Tango?

It already seems to have search, but it'd be nice to have this extended to all the methods. Basically, for a method "foo", there should be a free function "foo" that takes a regex string as the first param. That is, something like:

auto r = Regexp(pattern);
auto val = r.foo(params);

Should be interchangeable with:

auto val = foo(pattern, params);

Methods in VfsFile? to get modification, access and creation times could be usefull.

http://dsource.org/projects/tango/forums/topic/471

Seems like the trivial functions are missing from tango.text.convert.Utf ? I would like these for Phobos compatibility, and because they're handy...

char[] toUtf8(char[] input ... 

wchar[] toUtf16(wchar[] input ...

dchar[] toUtf32(wchar[] input ...

Did a workaround for now, but it would still be nice to have it in Tango. (to be clear they don't convert anything at all, but just copy it over)

Currently, Variant.toString returns a string representation of the type of data contained in the Variant. Ideally, it should return a representation of the data instead.

This probably won't work for structs, which don't need to define a toString method. But you can do this:

char[] toString(Variant v)
{
   if (v.isImplicitly!(long)) 
   {
      return Integer.toString(v.get!(long));
   }
   else if (v.isImplicitly!(real))
   {
      return Float.toString(v.get!(real));
   }
   else if (v.isImplicitly!(Object))
   {
      return v.get!(Object).toString;
   }
   else
   {
      // current implementation
      return v.type.toString;
   }
}

unittest
{
   Variant v = 5;
   assert ("5" == toString(v));
   auto o = new Object;
   v = o;
   assert (o.toString == toString(v));
   v = 7.83;
   assert (Float.toString(7.83) == toString(v));
   ubyte[] array = [];
   v = array;
   assert (typeid(ubyte[]).toString == toString(v));
}

This would, of course, be an inappropriate dependency if placed in Variant. So could you guys add a formatter to tango.text.convert?

Please provide an archive of downloads and documentation for each release. With breaking API changes and bugs in new releases, it's impractical to upgrade to every release. Without this, it's increadably painful to stay with an old release.

tango.core.Exception.AssertException?@tango/math/IEEE.d(279): Assertion failure

Using GDC 0.23 on linux 32 bit

The program in #1089 seems to fail with some archives. A simple look at the header dumps seems to suggest that this is caused by the wrong headers being compared, but I can't see an obvious reason off the bat.

in tango.io.compress.Zip extractArchive :

auto path = Path.join(dest, entry.info.name);

will get a incorrect path, for example, compressed D:\test.txt to D:\test.zip, and extract to D:, the path will be

D:/d:/test.txt

how about atleast run sample code once before commit the code?

void extractArchive(char[] archive, char[] dest)
{
    scope zr = new ZipBlockReader(archive);

    foreach( entry ; zr )
    {
        // Skip directories
        if( entry.info.name[$-1] == '/' ) continue;

        auto path = Path.join(dest, entry.info.name);
        scope fout = new FileConduit(path, FileConduit.WriteCreate);
        fout.output.copy(entry.open);
    }
}

The original issue has been fixed in unittest.sh (by linking libdl), the underlying problem isn't fixed though. This is due to the fact that different build methods would require different ways to specify this.

The only work for all solution would be to put libdl in dmd.conf, something which may be acceptable in that case.

The best thing though, would be to pragma (lib, "") working and interpreted by the compiler. This means that DMD needs to support it on Linux too, and GDC just needs to implement it.

The first is reported in http://d.puremagic.com/issues/show_bug.cgi?id=1663

This update FtpClient?.d FtpTelnet?.d and SocketConduit?.d(edited part of it to make a member of it protected so my class that inherited could do what it needed to.)

http://dsource.org/projects/tango/docs/current/tango.io.FileScan.html

There is no installer for tango user libraries in the lib directory. Installers exist for all other components.

Please make Tango installers print out the actions they're taking, AKA which files are getting copied to where. This will help users know where things are going and more easily diagnose improper installer behavior.