Re: Derelict SFML destructor crashes
On Tuesday, 18 December 2012 at 07:36:09 UTC, Rob T wrote: On Monday, 17 December 2012 at 04:40:39 UTC, Mike Parker wrote: First, please take all Derelict trouble-shooting problems to the Derelict forums[1]. I'm posting here because I was unable to register with the derelict forum. I filled out the registration form and press the register button, then a page opens with this message. An Error Has Occurred! Sorry, I've no idea what's going on there. I hope you can help me get registered. Thanks! If you email me the user name you want, I'll register an account for you.
Re: Derelict SFML destructor crashes
On Tuesday, 18 December 2012 at 08:14:01 UTC, Mike Parker wrote: On Tuesday, 18 December 2012 at 07:36:09 UTC, Rob T wrote: On Monday, 17 December 2012 at 04:40:39 UTC, Mike Parker wrote: First, please take all Derelict trouble-shooting problems to the Derelict forums[1]. I'm posting here because I was unable to register with the derelict forum. I filled out the registration form and press the register button, then a page opens with this message. An Error Has Occurred! Sorry, I've no idea what's going on there. I hope you can help me get registered. Thanks! If you email me the user name you want, I'll register an account for you. aldac...@gmail.com
Re: Derelict SFML destructor crashes
On Tuesday, 18 December 2012 at 07:36:09 UTC, Rob T wrote: On Monday, 17 December 2012 at 04:40:39 UTC, Mike Parker wrote: First, please take all Derelict trouble-shooting problems to the Derelict forums[1]. I'm posting here because I was unable to register with the derelict forum. I filled out the registration form and press the register button, then a page opens with this message. An Error Has Occurred! I tried a few times being very careful not to make any mistakes. I was going to post asking for a very small change to the derelict2 make process so that I could specify the compiler path. This is so I can pick a different version of dmd (or gdc, or ldc) as I have multiple versions installed (release and pre-release). I modded the make files to allow me to specify the compiler by full path, so I'm OK for now, this is just a suggested improvement for you to consider. I hope you can help me get registered. Thanks! --rt I had the same error actually. I just tried until it worked, which was the second time I tried.
Googling about D
Hi! In the beginning, sorry for my very bad English (and, perhaps, for stupid idea too) :) I hope we'll find common language :) I don't program with D a lot, but when I try to find information in google, I use that way: dlang something. And google very often tries to change it to slang something :) But I think, today, it's the best way. Because you can't look for d something. Because D - it's just a letter. dlang - it's a word, so you can find something more ease, than just with D. There're no any problem - you'll find necessary information on first-second page of searching results. Problems appear when I try to find all open-source solutions for D. For example, if I wanna find all web-frameworks and compare them. Recently, I tried to find package manager - it was a problem _for me_. I understand - there're package manager, but I can't compare all them, because I can't find them _quickly_. I think, it would more better, if D had official phrase for searchings. For example: d7ddb663512e4618b8f03d725d7f49c9e0ecc1e2 (sha1). If you'll find d7ddb663512e4618b8f03d725d7f49c9e0ecc1e2 web-framework - you'll find nothing. It's very cool. Because, if there aren't web framework for D - you'll just know about it. You won't move through 10 pages of noise from Google. Hash may be more short: bozf4qy (tinyurl for dlang.org) - it's more cognizable and still effective: bozf4qy game engine - nothing. It's cool. And try to use that: dlang game engine - something usefull and MUCH noise. And compare with that: JavaScript game engine. projects, libraries, etc. Perfect searching. It's very easy to integrate this technique with already existing projects: just add to README.md string bozf4qy. Or ask you forum engine to add small, non-contrast label bozf4qy before every message - so you can look for answers for problems, not only for projects and libraries. I think, it's very easy to use, to integrate. But what do you think about it? Why not? Sorry, if I spent your time for nothing :(
Re: Googling about D
12/18/2012 1:47 PM, egslava пишет: Hi! In the beginning, sorry for my very bad English (and, perhaps, for stupid idea too) :) I hope we'll find common language :) Hi! I think, it would more better, if D had official phrase for searchings. For example: d7ddb663512e4618b8f03d725d7f49c9e0ecc1e2 (sha1). If you'll find d7ddb663512e4618b8f03d725d7f49c9e0ecc1e2 web-framework - you'll find nothing. It's very cool. Because, if there aren't web framework for D - you'll just know about it. You won't move through 10 pages of noise from Google. Just LOL. Would be hard to integrate into a community at large but quite cool idea :) -- Dmitry Olshansky
Re: Googling about D
On Tuesday, 18 December 2012 at 09:47:24 UTC, egslava wrote: I don't program with D a lot, but when I try to find information in google, I use that way: dlang something. And google very often tries to change it to slang something :) But I think, today, it's the best way. Because you can't look for d something. Because D - it's just a letter. dlang - it's a word, so you can find something more ease, than just with D. Personally, if i am looking for anything related to D i first search with the prefix d programming language so i would search for d programming language something then if that fails i would maybe try dlang something but i currently only do that if i think that something could be found on dlang.org and this has so far worked well enough for me. tldr: Try searching with d programming language as a prefix first.
Re: Need help understanding Tuple
d coder:
template Tuple(T...) {
alias T Tuple;
}
enum Bar;
class Foo {
@Bar int a;
}
void main()
{
Foo foo = new Foo;
alias Tuple!(__traits(getAttributes, foo.a)) tp;
pragma(msg, tp);
}
As first step, don't use that Tuple, use std.typetuple.TypeTuple
instead. It's the same, but using the standardized name helps
readability.
Bye,
bearophile
Re: guidelines for parameter types
On Tuesday, 18 December 2012 at 06:34:55 UTC, Ali Çehreli wrote:
I don't think this is well known at all. :) I have thought
about these myself and came up with some guidelines at
http://ddili.org/ders/d.en
Thanks - I will study it. I see that you have covered also in,
out, inout, lazy, scope, and shared, so that should keep me busy
for a while.
I don't know how practical it is but it would be nice if the
price of copying an object could be considered by the compiler,
not by the programmer.
I agree - would be nice if compiler could do it but if it tried
some would just not be happy about the choices, no matter what.
According to D's philosophy structs don't have identities. If I
pass a struct by-value, the compiler should pick the fastest
method.
Even if there is a postblit? Maybe that would work, but say your
object were a reference counting type. If the compiler decided to
pass by ref sneakily for performance gain when you think it is by
value that might be a problem. Maybe not, though, as long as you
know how it works. I have seen that literal structs passed to a
function will not call the postblit - but Johnathan says this was
a bug in the way the compiler classifies literals.
That's sensible. (In practice though, it is rarely done in C++.
For example, if V is int and v is not intended to be modified,
it is still passed in as 'V v'.)
Absolutely. I read somewhere it was pedantic to do such things.
Then I read some other articles that touted the benefit, even on
an int, because the reader of (void foo(const int x) {...} )
knows x will/should not change, so it has clearer intentions for
future maintainers.
That makes a difference whether V is a value type or not. (It
is not clear whether you mean V is a value type.) Otherwise,
e.g. immutable(char[]) v has a legitimate meaning: The function
requires that the caller provides immutable data.
When is 'immutable(char[]) v' preferable to 'const(char[]) v'? If
you select 'const(char[]) v' instead, your function will not
mutate v and if it is generally a useful function it will even
accept 'char[]' that *is* mutable. I agree with the meaning you
suggest, but under what circumstances is it important to a
function to know that v is immutable as opposed to simply const?
| ref immutable(V) v | No need - restrictive with no benefit|
|| over 'ref const(V) v'|
I still has a different meaning: You must have an immutable V
and I need a reference to it. It may be that the identity of
the object is important and that the function would store a
reference to it.
This may be a use-case for it. You want to store a reference to v
and save it for later - so immutable is preferred over const. I
may be mistaken but I thought the thread on 'rvalue references'
talks about taking away the rights to take the address of any ref
parameter: http://forum.dlang.org/post/4f863629.6000...@erdani.com
| V* v | Use only when mutation of v is required. |
| | Prefer 'ref V v' unless null significant |
| | or unsafe manipulations desired |
Agreed.
Also, pointers may be needed especially when interfacing with C
and C++ libraries, but again, the D function can still take
'ref' and pass the address of that ref to the C function.
By 'unsafe manipulations' I meant things such as low level memory
management, interfacing with C and such. It may be that in the
future you will not be able to take the address of any 'ref'
parameter (see previous link). So, if you know you are going to
do interfacing with C or pointer work it and other non-safe code
it may be best to just take 'V* v'.
Again, if the function demands immutable(V), which may be null,
then it actually has some use.
I agree - I just don't know yet when a function would demand
'immutable(V)' over 'const(V)'.
| T t | T is primitive, dynamic array, or assoc |
| | array (i.e. cheap/shallow copies). For |
| | generic code no knowledge of COW or|
| | cheapness so prefer 'ref T t' |
I am not sure about that last guideline. I think we should
simply type T and the compiler does its magic. I don't know how
practical my hope is.
Besides, we don't know whether T is primitive or not. It can be
anything. If T is int, 'ref T t' could actually be slower due
to the pointer indirection due to ref.
Agreed. In a separate thread
http://forum.dlang.org/thread/opufykfxwkkjchqcw...@forum.dlang.org
I included some timings of passing a struct as 'in S', 'in ref
S', and 'const ref S'. The very small sizes, matching up to sizes
of primitives, showed litte if any benefit of by value over ref.
Maybe the test/benchmark was flawed? But for big sizes, the by
reference clearly won by a large margin. The problem with
template code is you don't have any knowledge and the cost of 'by
value' is unbounded, whereas difference between 'int t'
Re: Need help understanding Tuple
On Tuesday, 18 December 2012 at 11:06:12 UTC, d coder wrote: Greetings Somebody please help me understand why we need the Tuple template in the following code. Does not __traits(getAttributes, foo.a) return a tuple? So what is the Tuple template doing here? Converting a tuple to a tuple? Also where to learn more about tuples in D. Info in TDPL is sketchy. The spec goes into tuples in some depth: http://dlang.org/tuple.html
Re: Googling about D
On Tuesday, 18 December 2012 at 11:39:29 UTC, Nekroze wrote: On Tuesday, 18 December 2012 at 09:47:24 UTC, egslava wrote: I don't program with D a lot, but when I try to find information in google, I use that way: dlang something. And google very often tries to change it to slang something :) But I think, today, it's the best way. Because you can't look for d something. Because D - it's just a letter. dlang - it's a word, so you can find something more ease, than just with D. Personally, if i am looking for anything related to D i first search with the prefix d programming language so i would search for d programming language something then if that fails i would maybe try dlang something but i currently only do that if i think that something could be found on dlang.org and this has so far worked well enough for me. tldr: Try searching with d programming language as a prefix first. For example, I try to use that phrase: d programming language sha256 I needed only sha-256 library for my course work. Only. Don't ask me why :) And I really don't know: is there RIGHT library or not? And there are a lot of noise in google results. There're much noise and there're few common cipher libraries. If I know - there aren't another libraries - I'll try to fit existance libraries for my purposes. If I know - there is library more fitted for my purposes - I'll look for that. It's very easy add to web-page: bozf4qy (or something else) And all problems about search are solved: you will look only for D2 libraries and solutions. Why not?
Re: Googling about D
On 12/18/2012 08:12 AM, egslava wrote: For example, I try to use that phrase: d programming language sha256 I needed only sha-256 library for my course work. Only. Don't ask me why :) And I really don't know: is there RIGHT library or not? And there are a lot of noise in google results. There're much noise and there're few common cipher libraries. Wouldn't one just use OpenSSL? FYI - I search for d language something. -- Matthew Caron, Software Build Engineer Sixnet, a Red Lion business | www.sixnet.com +1 (518) 877-5173 x138 office
Re: Derelict SFML destructor crashes
On Tuesday, 18 December 2012 at 07:36:09 UTC, Rob T wrote: On Monday, 17 December 2012 at 04:40:39 UTC, Mike Parker wrote: First, please take all Derelict trouble-shooting problems to the Derelict forums[1]. I'm posting here because I was unable to register with the derelict forum. I filled out the registration form and press the register button, then a page opens with this message. An Error Has Occurred! I tried a few times being very careful not to make any mistakes. I *think* I've got it sorted. If you try again, it should work.
Re: Googling about D
Wouldn't one just use OpenSSL? I just looked for something simple like: auto sha = sha256_digest(blah); FYI - I search for d language something. And I couldn't find that easily :( I found some library, but I had been modificating that about two hours. But, please, ask me. Is it hard to add some string to your site? Just add string - that will do live easier for many D2 users.
Re: guidelines for parameter types
On 12/18/2012 04:51 AM, Dan wrote:
On Tuesday, 18 December 2012 at 06:34:55 UTC, Ali Çehreli wrote:
I don't think this is well known at all. :) I have thought about these
myself and came up with some guidelines at http://ddili.org/ders/d.en
Thanks - I will study it. I see that you have covered also in, out,
inout, lazy, scope, and shared, so that should keep me busy for a while.
For convenience, here are the chapters and guidelines that are relevant:
1) Immutability:
http://ddili.org/ders/d.en/const_and_immutable.html
Quoting:
* As a general rule, prefer immutable variables over mutable
ones.
* Define constant values as enum if their values can be
calculated at compile time. For example, the constant value of
seconds per minute can be an enum:
enum int secondsPerMinute = 60;
* There is no need to specify the type explicitly if it can be
inferred from the right hand side:
enum secondsPerMinute = 60;
* Consider the hidden cost of enum arrays and enum associative
arrays. Define them as immutable variables if the arrays are
large and they are used more than once in the program. Specify
variables as immutable if their values will never change but
cannot be known at compile time. Again, the type can be
inferred:
immutable guess = read_int(What is your guess);
* If a function does not modify a parameter, specify that
parameter as const. This would allow both mutable and immutable
variables to be passed as arguments:
void foo(const char[] s)
{
// ...
}
void main()
{
char[] mutableString;
string immutableString;
foo(mutableString); // ← compiles
foo(immutableString);// ← compiles
}
* Following from the previous guideline, consider that const
parameters cannot be passed to functions taking immutable. See
the section titled Should a parameter be const or immutable?
above.
* If the function modifies a parameter, leave that parameter as
mutable (const or immutable would not allow modifications
anyway):
import std.stdio;
void reverse(dchar[] s)
{
foreach (i; 0 .. s.length / 2) {
immutable temp = s[i];
s[i] = s[$ - 1 - i];
s[$ - 1 - i] = temp;
}
}
void main()
{
dchar[] salutation = hellod.dup;
reverse(salutation);
writeln(salutation);
}
The output:
olleh
2) const ref Parameters and const Member Functions:
http://ddili.org/ders/d.en/const_member_functions.html
Quoting:
* To give the guarantee that a parameter is not modified by the
function, mark that parameter as in, const, or const ref.
* Mark member functions that do not modify the object as const:
struct TimeOfDay
{
// ...
string toString() const
{
return format(%02s:%02s, hour, minute);
}
}
This would make the struct (or class) more useful by removing an
unnecessary limitation. The examples in the rest of the book
will observe this guideline.
3) Constructor and Other Special Functions:
http://ddili.org/ders/d.en/special_functions.html
Quoting:
Immutability of constructor parameters
In the Immutability chapter we have seen that it is not easy to
decide whether parameters of reference types should be defined
as const or immutable. Although the same considerations apply
for constructor parameters as well, immutable is usually a
better choice for constructor parameters.
The reason is, it is common to assign the parameters to members
to be used at a later time. When a parameter is not immutable,
there is no guarantee that the original variable will not
change by the time the member gets used.
I don't know how practical it is but it would be nice if the price of
copying an object could be considered by the compiler, not by the
programmer.
I agree - would be nice if compiler could do it but if it tried some
would just not be happy about the choices, no matter what.
According to D's philosophy structs don't have identities. If I pass a
struct by-value, the compiler should pick the fastest method.
Even if there is a postblit? Maybe that would work, but say your object
were a reference counting type. If the compiler decided to pass by ref
sneakily for performance gain when you think it is by value that might
be a problem. Maybe not, though, as long as you know how it works. I
have seen that literal structs passed to a function will not call the
postblit - but Johnathan says this was a bug in the way the compiler
classifies literals.
I am also keeping in mind that struct objects are supposed to be treated
as simple values without identities:
http://dlang.org/struct.html
Quoting:
A struct is defined to not have an identity; that is, the
implementation is free to make bit copies of the struct as
convenient.
That's sensible. (In practice though, it is rarely done in C++. For
example,
Re: variable x cannot be read at compile time (ctfe)
maarten van damme: How can this be? Maybe there are some mistakes in your assumptions. Bye, bearophilwe
Re: guidelines for parameter types
On Tue, Dec 18, 2012 at 01:51:31PM +0100, Dan wrote:
On Tuesday, 18 December 2012 at 06:34:55 UTC, Ali Çehreli wrote:
[...]
That makes a difference whether V is a value type or not. (It is
not clear whether you mean V is a value type.) Otherwise, e.g.
immutable(char[]) v has a legitimate meaning: The function
requires that the caller provides immutable data.
When is 'immutable(char[]) v' preferable to 'const(char[]) v'? If
you select 'const(char[]) v' instead, your function will not mutate
v and if it is generally a useful function it will even accept
'char[]' that *is* mutable. I agree with the meaning you suggest,
but under what circumstances is it important to a function to know
that v is immutable as opposed to simply const?
It's not just about whether the function mutates something or not.
Sometimes the function counts on the data not changing, ever. For
example, if you're implementing a library AA type, you'd want the key to
be immutable so that whatever hash value you computed for the bucket
will not suddenly become invalid just because the user changed it from
underneath you:
// Problematic example
struct AA {
struct Bucket {
const(char)[] key;
uint hash;
const(char)[] value;
Bucket* next;
}
Bucket*[] htable;
void addEntry(const(char)[] key, const(char)[] value) {
// N.B.: Bucket now stores a reference to key
auto buck = new Bucket(key, hashof(key), value);
// The validity of this depends on the
// referenced key not changing, ever.
htable[buck.hash % htable.length] = buck;
}
const(char)[] opIndex(const(char)[] key) {
auto hash = hashof(key);
auto buck = htable[hash % htable.length];
while (buck) {
if (buck.key == key)
return buck.value;
buck = buck.next;
}
// throw out of bounds error here
}
}
void main() {
AA aa;
char[] myKey = abc;
// OK: char[] implicitly converts to const(char)[].
aa.addEntry(myKey, some value);
myKey[0] = 'c'; // --- oops! now the entry's Bucket is wrong!
auto v = aa[abc]; // this will throw, 'cos the
// right slot is found but the
// entry's .key value has
// changed, so it won't match
auto u = aa[cbc]; // in all likelihood, this will
// also throw because the hash
// of cbc is unlikely to be
// equal to the hash of abc so
// we won't find the right slot
}
In this case, the key passed to .addEntry *must* be immutable. That's
the only way to guarantee that the AA's internal structures won't get
invalidated by outside code.
T
--
Skill without imagination is craftsmanship and gives us many useful objects
such as wickerwork picnic baskets. Imagination without skill gives us modern
art. -- Tom Stoppard
hello world with glib
Hi, I'm trying to get a hello world going to call a C function from
[1]glib. I'm having problems compiling, what would the correct command
line options?
% dmd -I/usr/include/glib-2.0 hello.d -L-L/usr/local/lib -L-lglib-2.0
hello.d(3): Error: undefined identifier GDateTime
hello.d(3): Error: undefined identifier GTimeZone
% cat hello.d
import std.stdio;
extern(C) GDateTime *g_date_time_new_now (GTimeZone *tz);
void main() {
writeln(Hello, world);
GDateTime *gdt;
}
I've got the [2]Interfacing to C page bookmarked :-)
Thanks for any help, Sonia.
References
1. http://developer.gnome.org/glib/2.34/
2. http://dlang.org/interfaceToC.html
Re: Googling about D
On Tue, Dec 18, 2012, at 22:39, Nekroze wrote: On Tuesday, 18 December 2012 at 09:47:24 UTC, egslava wrote: I don't program with D a lot, but when I try to find information in google, I use that way: dlang something. And google very often tries to change it to slang something :) But I think, today, it's the best way. Because you can't look for d something. Because D - it's just a letter. dlang - it's a word, so you can find something more ease, than just with D. Personally, if i am looking for anything related to D i first search with the prefix d programming language so i would search for d programming language something then if that fails i would maybe try dlang something but i currently only do that if i think that something could be found on dlang.org and this has so far worked well enough for me. tldr: Try searching with d programming language as a prefix first. See this FAQ article [1]. [1] http://dlang.org/faq.html#q1_1
Re: guidelines for parameter types
On Tuesday, 18 December 2012 at 18:08:18 UTC, H. S. Teoh wrote: It's not just about whether the function mutates something or not. Sometimes the function counts on the data not changing, ever. For example, if you're implementing a library AA type, you'd want the key to be immutable so that whatever hash value you computed for the bucket will not suddenly become invalid just because the user changed it from underneath you: [snip] In this case, the key passed to .addEntry *must* be immutable. That's the only way to guarantee that the AA's internal structures won't get invalidated by outside code. Thanks! You and Ali have presented good examples where 'ref immutable(T|V) t|v' trumps 'ref const(T|V) t|v' and if I understand them correctly it is for whenever the instance method (in the case of a member function) will hold onto the argument for later use. I'll refine my selection process accordingly. Thanks, Dan
Re: Derelict SFML destructor crashes
On Tuesday, 18 December 2012 at 13:47:43 UTC, Mike Parker wrote: I *think* I've got it sorted. If you try again, it should work. I tried it again just now and it worked. Thanks! --rt
Re: variable x cannot be read at compile time (ctfe)
My only assumption is that -version=runtime doesn't utilize ctfe and the other does. The rest is simple timing on both linux and windows and ctfe is way slower... 2012/12/18 bearophile bearophileh...@lycos.com: maarten van damme: How can this be? Maybe there are some mistakes in your assumptions. Bye, bearophilwe
Re: hello world with glib
On Tuesday, 18 December 2012 at 18:24:03 UTC, Sonia Hamilton wrote: [1]glib. I'm having problems compiling, what would the correct command line options? % dmd -I/usr/include/glib-2.0 hello.d -L-L/usr/local/lib -L-lglib-2.0 hello.d(3): Error: undefined identifier GDateTime hello.d(3): Error: undefined identifier GTimeZone Your problem isn't the command line options, but that you're missing definitions of GDateTime and GTimeZone. You'll need to define those somewhere, perhaps the top of your file here for testing, so that D can know what they are. I've got the [2]Interfacing to C page bookmarked :-) Thanks for any help, Sonia. References 1. http://developer.gnome.org/glib/2.34/ 2. http://dlang.org/interfaceToC.html You might want to add this series as well, starting with part 1: http://www.gamedev.net/blog/1140/entry-2254003-binding-d-to-c/
Re: hello world with glib
On Tuesday, 18 December 2012 at 19:21:09 UTC, Mike Parker wrote: On Tuesday, 18 December 2012 at 18:24:03 UTC, Sonia Hamilton wrote: [1]glib. I'm having problems compiling, what would the correct command line options? % dmd -I/usr/include/glib-2.0 hello.d -L-L/usr/local/lib -L-lglib-2.0 hello.d(3): Error: undefined identifier GDateTime hello.d(3): Error: undefined identifier GTimeZone Your problem isn't the command line options, but that you're missing definitions of GDateTime and GTimeZone. You'll need to define those somewhere, perhaps the top of your file here for testing, so that D can know what they are. I just took a look at the GLib docs and see that both of these are opaque structs, so this should do it for you: struct GDateTime; struct GTimeZone;
Re: Help with Out Of Memory D v1.0
- Original Message -
Greetings!
I have this program that zips a file and everything works perfectly, if
the files are small enough. But, I am having to zip files that are
getting more and more extreme in size and I am running out of memory.
Here is the output when executing a small program to zip a folder:
0:36:59.76zipafile
Zipping file no 0 huge\0.pdf
** PLEASE WAIT FOR FILE #0 TO BE ZIPPED **
Zipping file no 1 huge\1.exe
** PLEASE WAIT FOR FILE #1 TO BE ZIPPED **
Zipping file no 2 huge\2.exe
** PLEASE WAIT FOR FILE #2 TO BE ZIPPED **
Zipping file no 3 huge\updates\p.zip
** PLEASE WAIT FOR FILE #3 TO BE ZIPPED **
Zipping file no 4 huge\updates\q.html
** PLEASE WAIT FOR FILE #4 TO BE ZIPPED **
Zipping file no 5 huge\updates\z.exe
** PLEASE WAIT FOR FILE #5 TO BE ZIPPED **
finished all files...
** PLEASE WAIT FOR ZIP FILE TO BE CREATED **
Error: Out of memory
0:37:56.26
This is the program in question...
import std.stdio;
import std.file;
import std.date;
import std.zip;
import std.zlib;
import jic.libs.MyFile;
int main(char[][] args)
{
char[] folder = rc:\tmp\huge;
ZipAFolder(folder);
return 0;
}
void ZipAFolder(char[] zipFolder)
{
char[] fdname = std.path.getDirName(zipFolder);
char[][] allfiles = std.file.listdir(zipFolder,*);
char[] zipFile = zipFolder ~ .zip;
int FilesCnt = 0;
std.zip.ZipArchive zr;
zr = new std.zip.ZipArchive();
int one = 0;
foreach(char[] f; allfiles)
{
char[] f0 = std.string.replace(f,fdname ~ \\,); // Filename
writefln(Zipping file no ~ std.string.toString(one) ~ ~ f0);
ArchiveMember am = new ArchiveMember();
am.compressionMethod = 8;
am.name = f0;
//am.expandedData = cast(ubyte[]) f.read();
am.expandedData = cast(ubyte[]) f.read();
am.expandedSize = am.expandedData.length;
FileData fd0 = GetFileInfo(f);
long usedT0;
if (fd0.creationTime fd0.modifiedTime)
{
usedT0 = fd0.creationTime;
}
else
{
usedT0 = fd0.modifiedTime;
}
am.time = std.date.toDosFileTime(usedT0);
zr.addMember(am);
writefln( ** PLEASE WAIT FOR FILE # ~ std.string.toString(one) ~ TO
BE ZIPPED ** );
one++;
}
writefln(finished all files...);
writefln( ** PLEASE WAIT FOR ZIP FILE TO BE CREATED ** );
std.file.write(zipFile, cast(byte[])zr.build());
writefln( ** ~ std.string.toString(one) ~ FILES ZIPPED ** );
writefln(zipFile ~ created.);
//return 1;
}
As you can see, the last two writelns do not get printed because of the
Out Of Memory. Any help would be greatly appreciated. Thanks.
josé
So, can anyone help suggesting how to change this line,
std.file.write(zipFile, cast(byte[])zr.build());
so that do not get the out of memory? I tried a few things, but I can not
compile it. Thanks so much.
josé
Re: hello world with glib
On 12/18/12 20:23, Mike Parker wrote:
On Tuesday, 18 December 2012 at 19:21:09 UTC, Mike Parker wrote:
On Tuesday, 18 December 2012 at 18:24:03 UTC, Sonia Hamilton wrote:
[1]glib. I'm having problems compiling, what would the correct command
line options?
% dmd -I/usr/include/glib-2.0 hello.d -L-L/usr/local/lib -L-lglib-2.0
hello.d(3): Error: undefined identifier GDateTime
hello.d(3): Error: undefined identifier GTimeZone
Your problem isn't the command line options, but that you're missing
definitions of GDateTime and GTimeZone. You'll need to define those
somewhere, perhaps the top of your file here for testing, so that D can know
what they are.
I just took a look at the GLib docs and see that both of these are opaque
structs, so this should do it for you:
struct GDateTime;
struct GTimeZone;
And if you don't want to do all of that manually, you could use
http://repo.or.cz/w/girtod.git
which would make a simple glib D hello-world program look like
import glib = gtk2.glib2;
import std.stdio, std.conv;
void main() {
auto tz = glib.TimeZone.new_local();
scope (exit) tz.unref();
auto dt = glib.DateTime.new_now(tz);
scope (exit) dt.unref();
writeln(Hello World! It is ~ to!string(dt.format(%c)));
}
Compile with
gdc -fdeprecated -O2 -I $PATH_TO_GIRTOD glibhello.d
$PATH_TO_GIRTOD/gtk2/glib2.o `pkg-config --libs glib-2.0`
This might only work with GDC right now; I have no idea about DMD - never tried
it.
There are other gtk bindings out there (eg gtkd) that may work with that
compiler
and probably support glib too.
artur
Re: Googling about D
Yes, I know it, but I didn't suppose to rename the language :) No! No, no, no! :) I supposed to all d users just add some tag for their libraries. It's simple. It doesn't require change the name of the language. It doesn't change something, except few lines of your CMS code :( Really, why not?
Re: Googling about D
On Tue, Dec 18, 2012 at 4:47 AM, egslava egsl...@gmail.com wrote: Hi! In the beginning, sorry for my very bad English (and, perhaps, for stupid idea too) :) I hope we'll find common language :) I don't program with D a lot, but when I try to find information in google, I use that way: dlang something. And google very often tries to change it to slang something :) But I think, today, it's the best way. Because you can't look for d something. Because D - it's just a letter. dlang - it's a word, so you can find something more ease, than just with D. There're no any problem - you'll find necessary information on first-second page of searching results. Problems appear when I try to find all open-source solutions for D. For example, if I wanna find all web-frameworks and compare them. Recently, I tried to find package manager - it was a problem _for me_. I understand - there're package manager, but I can't compare all them, because I can't find them _quickly_. I think, it would more better, if D had official phrase for searchings. For example: d7ddb663512e4618b8f03d725d7f49**c9e0ecc1e2 (sha1). If you'll find **d7ddb663512e4618b8f03d725d7f49**c9e0ecc1e2 web-framework - you'll find nothing. It's very cool. Because, if there aren't web framework for D - you'll just know about it. You won't move through 10 pages of noise from Google. While that's certainly the most interesting solution I've heard to this sort of problem, in my own opinion I'd think that having a centralized index and package tool (much like ruby's gem, python's pip, lua's luarocks) would be a better way of handling the issue - I remember seeing a bit of talk about this some months (years?) ago but have since been too busy to worry about it. :D Best regards, Jeremy Sandell
Re: Googling about D
I often search libraries on Github — it allows to filter results by language, and probably most D libraries are anyway hosted there.
Re: Writing unicode strings to the console
On Tuesday, 18 December 2012 at 00:29:56 UTC, Jeremy DeHaan wrote: I was playing with unicode strings the other day, and have been searching for a way to correctly write unicode to the console. If I try something like: dstring String = さいごの果実; writeln(String); All I get is a bunch of nonsense as if it converts the dstring into a regular string. Is it possible to write the unicode string to the console correctly? http://forum.dlang.org/thread/suzymdzjeifnfirtb...@dfeed.kimsufi.thecybershadow.net#post-suzymdzjeifnfirtbnrc:40dfeed.kimsufi.thecybershadow.net
Re: MS ODBC encoding issue
On Monday, 10 December 2012 at 14:43:08 UTC, Regan Heath wrote: Ahh, of course. Now I'm having linking issues :p I'm using VisualD and I've added odbc32.lib to the right place, but some symbols are still missing - specifically the W versions. I've dumped the symbols in the DMC odbc32.lib and it's missing those symbols. R I have such extra lib files to link successfully but I don't find any way to upload here.Sorry.
Re: Writing unicode strings to the console
On Tuesday, 18 December 2012 at 00:29:56 UTC, Jeremy DeHaan wrote: I was playing with unicode strings the other day, and have been searching for a way to correctly write unicode to the console. If I try something like: dstring String = さいごの果実; writeln(String); All I get is a bunch of nonsense as if it converts the dstring into a regular string. Is it possible to write the unicode string to the console correctly? If all else fails, you can always just print to file instead. That's what I do.
