Re: Deleting a file with extsion *.FIFO in Windows
On Thursday, 24 May 2018 at 11:31:15 UTC, bauss wrote: On Thursday, 24 May 2018 at 06:59:47 UTC, Vino wrote: Hi All, Request your help on how to delete a file which has the extension .fifo (.javast.fifo) in Windows. From, Vino.B What exactly is your issue with it? Hi Bauss, We have a java program which creates a file with extension .fifo and we have another program written in D to clean up the old file, so the D code is not able to delete these files using any of the D function provided it states "Access Denied" we tried to provide the full access manually even then it is not able to delete such files. From, Vino.B
Re: How do I make this function thread safe?
On Thursday, 31 May 2018 at 19:26:12 UTC, Dr.No wrote: My application create some HTML which is then converted to PDF by wkhtmltopdf library. I'm trying to figure out how make the PDF generation run parallel, currently, it's running linearly. It looks like wkhtmltopdf does not support multithreaded use; see here: https://github.com/wkhtmltopdf/wkhtmltopdf/issues/1711 So, if you want to run the conversions in parallel, you will have to use separate processes.
How do I make this function thread safe?
My application create some HTML which is then converted to PDF by
wkhtmltopdf library. I'm trying to figure out how make the PDF
generation run parallel, currently, it's running linearly. My
guess is wkhtmltopdf internal variables is preventing
parallelization. But I'm new to parallization and I don't know
how to solve that by now. I guesses that that function from an
external thread would make each wkhtmltopdf initilization run on
its memory space, similiar to a process. But since it is not
working, I guess this isn't how it's working.
I'm not asking to just give me the code ready (if it's somehow
complex) brather some directions, how I may archive that.
Here's my current code:
void genPDFImplt(string htmlFilename, string outputpdfFilename)
{
import pdf;
import std.string : toStringz;
/* Init wkhtmltopdf in graphics less mode */
wkhtmltopdf_init(0);
wkhtmltopdf_global_settings *gs =
wkhtmltopdf_create_global_settings();
/* We want the result to be storred in the file called test.pdf
*/
wkhtmltopdf_set_global_setting(gs, "out",
outputpdfFilename.toStringz);
wkhtmltopdf_object_settings *os =
wkhtmltopdf_create_object_settings();
/* We want to convert to convert the qstring documentation page
*/
wkhtmltopdf_set_object_setting(os, "page",
htmlFilename.toStringz);
/* Create the actual converter object used to convert the pages
*/
wkhtmltopdf_converter * c = wkhtmltopdf_create_converter(gs);
static if(0) {
/* Call the progress_changed function when progress changes */
wkhtmltopdf_set_progress_changed_callback(c,
_progress_changed);
/* Call the phase _changed function when the phase changes */
wkhtmltopdf_set_phase_changed_callback(c, _phase_changed);
/* Call the error function when an error occures */
wkhtmltopdf_set_error_callback(c, _error);
/* Call the waring function when a warning is issued */
wkhtmltopdf_set_warning_callback(c, _warning);
}
scope(exit) {
/* Destroy the converter object since we are done with it */
wkhtmltopdf_destroy_converter(c);
/* We will no longer be needing wkhtmltopdf funcionality */
wkhtmltopdf_deinit();
}
wkhtmltopdf_add_object(c, os, null);
/* Perform the actual convertion */
wkhtmltopdf_convert(c);
}
called from a loop like this:
foreach(string file; parallel(files)) {
auto res = doSomething(file);
auto htmlfile = genHtmlFile(res);
auto pdffile = genTmpPDFFilename();
genPDFImplt(htmlfiel, pdffile);
}
Running in a dual core CPU, with 4 threads. It's genrating
one PDF per iteration rather 4. I've made sure already it's the
genPDFImplt() which is doing that.
Re: OT: Parsing object files for fun and profit
On Thursday, 31 May 2018 at 18:33:37 UTC, Ali Çehreli wrote:
On 05/31/2018 09:49 AM, Adam D. Ruppe wrote:
> Should be fairly simple to follow, just realize that the
image is a 2d
> block for each char and that's why there's all those
multiplies and
> divides.
I remember doing similar things with fonts to add Turkish
characters to Digital Research and Wordperfect products (around
1989-1992). Localizing by patching compiled code was fun. :)
My happiest accomplishment was localizing Ventura Publisher
"cleanly" after realizing that their language-related
"resource" file was just an object file compiled from a simple
C source code which had just an array of strings in it:
char * texts[] = {
"yes",
"no",
// ...
};
I parsed the object file to generate C source code, translated
the C source code, and finally compiled it again. Voila!
Ventura Publisher in Turkish, and everything lined-up
perfectly. :) Before that, one had to patch the object file to
abbreviate "evet" on top of "yes", "hayır" on top of "no", etc.
Ali
Look for bdf files. This is an quite old X-windows bitmap font
file format that has the big advantage of being a simple text
format. So it is easy to parse and transform. There are quite
some fonts existing in that format.
https://en.wikipedia.org/wiki/Glyph_Bitmap_Distribution_Format
I had used it in an embedded project in the 90s and it was simple
enough that a 80186 based terminal could handle bitmap
proportional fonts without breaking a sweat.
OT: Parsing object files for fun and profit
On 05/31/2018 09:49 AM, Adam D. Ruppe wrote:
> Should be fairly simple to follow, just realize that the image is a 2d
> block for each char and that's why there's all those multiplies and
> divides.
I remember doing similar things with fonts to add Turkish characters to
Digital Research and Wordperfect products (around 1989-1992). Localizing
by patching compiled code was fun. :)
My happiest accomplishment was localizing Ventura Publisher "cleanly"
after realizing that their language-related "resource" file was just an
object file compiled from a simple C source code which had just an array
of strings in it:
char * texts[] = {
"yes",
"no",
// ...
};
I parsed the object file to generate C source code, translated the C
source code, and finally compiled it again. Voila! Ventura Publisher in
Turkish, and everything lined-up perfectly. :) Before that, one had to
patch the object file to abbreviate "evet" on top of "yes", "hayır" on
top of "no", etc.
Ali
Re: Constructing text with astericks
On Thursday, 31 May 2018 at 16:05:40 UTC, aberba wrote:
That doesn't sound like a trivial thing to do. Ha ha
Oh, it isn't that bad if you can get a font as an image file (and
have the code to load such image files... but I do!)
Take a look at my little answer (SPOILERS THOUGH! Maybe skip to
bottom of this message if you don't want to actually see the
working answer just to get more help):
---
class Font {
import arsd.png;
enum charWidth = 8;
enum charHeight = 8;
TrueColorImage image;
// font.png is just a screenshot of monospaced font written out
in 8x8 cells
// (that's where the charWidth and charHeight things above come
from), one after
// another in the image
this() {
image = readPng("font.png").getAsTrueColorImage();
}
char[charWidth][charHeight] getChar(char c) {
// just finding the character offset in the image
auto entriesPerLine = image.width / charWidth;
auto charX = c % entriesPerLine;
auto charY = c / entriesPerLine;
auto xOffset = charX * charWidth;
auto yOffset = charY * charHeight;
char[charWidth][charHeight] buffer;
// then drawing it to the buffer
foreach(y; 0 .. charHeight) {
foreach(x; 0 .. charWidth) {
// if it is not transparent, use *, otherwise,
use space.
buffer[y][x] = (image.getPixel(xOffset + x, yOffset + y).a >
0 ? '*' : ' ');
}
}
return buffer;
}
}
// this represents the screen. It is buffered so we can jump
around x and y to make
// lines of stars instead of trying to just do one line of font
"pixels" at a time...
char[70][24] screenBuffer;
int bufferCursorX;
int bufferCursorY;
// to draw an individual character, we loop through the character
and copy its pixels
// line by line...
void writeCharToBuffer(int x, int y,
char[Font.charWidth][Font.charHeight] ch) {
foreach(a; 0 .. Font.charHeight)
screenBuffer[y + a][x .. x + Font.charWidth] = ch[a][];
}
// and to write a string, we do the same for each char. This also
just keeps track
// of the cursor position so subsequent calls will add the chars
after the last ones.
//
// Note this may throw a RangeError when it runs out of space!!
void writeStringToBuffer(Font font, string str) {
foreach(char ch; str) {
writeCharToBuffer(bufferCursorX, bufferCursorY,
font.getChar(ch));
bufferCursorX += Font.charWidth;
if(bufferCursorX + Font.charWidth >
screenBuffer[bufferCursorY].length) {
// the next character would go off the screen, so wrap this
char
// to the next line
bufferCursorY += Font.charHeight;
bufferCursorX = 0;
}
}
}
// then once everything is buffered, writing it to the actual
screen
// is as simple as looping over the buffered lines and outputting
them!
void writeBufferToScreen() {
import std.stdio;
foreach(line; screenBuffer)
writeln(line);
}
void main() {
// clear the screen...
foreach(ref line; screenBuffer)
line[] = ' ';
// load the font
auto font = new Font();
// write our string to the buffer
writeStringToBuffer(font, "Hello, world!");
// and the buffer to the screen
writeBufferToScreen();
}
---
Should be fairly simple to follow, just realize that the image is
a 2d block for each char and that's why there's all those
multiplies and divides.
You can grab the font.png I used from here:
http://arsdnet.net/font.png
(it is the old IBM PC font)
And the dependencies to load that png are:
https://github.com/adamdruppe/arsd/blob/master/color.d
https://github.com/adamdruppe/arsd/blob/master/png.d
then pretty simple compile and run should get you the hello world.
spawn, send, and receive
I am fiddling again with writing a D version of Me TV to compare with the C++ (already declared dead), and the Rust version (currently the 'real' version). From the main thread (which eventually becomes the GTK+3 event loop thread) I spawn three threads to create "actors" that pass messages. Actually it is a pipeline. 1 → 2 → 3 The intention will then be that Actor 3 communicates with the GTK+3 event loop in whatever way is allowed. All three threads seem to start. 3 always goes straight into receive. In some circumstances 2 sends messages to 3 before it enters it's receive, in other circumstances it goes straight into receive. 1 alternates between a listening activity not to do with the threads and a receive (for termination). 1 and 2 are seen to execute sends to the correct Tid, but no receive ever executes. I tried putting Variant as the last option to see if there were message but just of the wrong type, and… no message received. It seems that receive is blocking and never being triggered even though provably there are sends that should trigger a receive. So I assume I am doing something very silly that causes this, or my code is wrong in some other way. The code is at: https://github.com/russel/Me-TV_D src/inotify_daemon.d contains Actor 1 code. src/frontend_manager.d contains Actor 2 code. src/control_window.d contains Actor 3 code. src/main.d has the startup code. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Constructing text with astericks
On Wednesday, 30 May 2018 at 23:11:06 UTC, Adam D. Ruppe wrote: On Wednesday, 30 May 2018 at 22:57:06 UTC, aberba wrote: How will you approach this problem in D idiomatically? Well, I never bother with "idiomatically", so I can't speak to that, but a simple solution that would work is to realize that what you're basically asking for here is a bitmap. Each letter in your "font" would be a little bitmap that you copy into a destination buffer - itself a larger bitmap. Then, when it is complete, you can draw the destination buffer line by line to the screen. The data for your font may just be a bunch of string arrays in source, or an actual bitmap file you create outside the program and load at runtime or something like that. Just remember that you can't just `buffer ~= letter` - you need to do line by line since the two bitmaps will have different sizes. That doesn't sound like a trivial thing to do. Ha ha
Re: no [] operator overload for type Chunks!(char[])
On 5/30/18 5:41 PM, Malte wrote: On Wednesday, 30 May 2018 at 21:27:44 UTC, Ali Çehreli wrote: On 05/30/2018 02:19 PM, Malte wrote: Why does this code complain at the last line about a missing [] operator overload? auto buffer = new char[6]; auto chunked = buffer.chunks(3); chunked[1][2] = '!'; Same happens with wchar. Dchar and byte work as expected. UTF-8 auto decoding strikes again. :) Even though the original container is char[], passing it through Phobos algorithms generated range of dchar. The thing is, those dchar elements are generated (decoded from chars) "on the fly" as one iterates over the range. Which means, there is no array of dchar to speak of, so there is no random access. I see. Not what I would have expected, but makes sense for people working with UTF-8 strings. Thanks for the fast answer. You can use byCodeUnit to turn it back into an indexable range: auto chunked = buffer.byCodeUnit.chunks(3); -Steve
Re: question about keeeping reference to toStringz()
On Thursday, 31 May 2018 at 02:10:53 UTC, Mike Parker wrote: On Thursday, 31 May 2018 at 01:12:34 UTC, Dr.No wrote: is foo() is being called from a thread, how I am supposed to keep cstring "alive"? As Jonathan explained, you don't have to worry about it if foo() itself doesn't assign the pointer to anything internally. That will be the case for most C functions. Well-behaved functions that need to keep the string around will copy it. That said, you need to be sure you understand fully what any C function you call is doing with the strings, or pointers to any memory allocated by the GC, that you pass to them. In the rare cases where the C function does keep the pointer and you do need to keep a reference (if you don't have one already), the simplest approach is this one: import core.memory; GC.addRoot(cstring); Then, when you no longer need it: GC.removeRoot(cstring); https://dlang.org/phobos/core_memory.html#.GC.addRoot Actually thank you for this. I had no idea you could do that with the GC.
Re: Stack traces with DMD on OSX
On Thursday, 31 May 2018 at 09:11:41 UTC, pineapple wrote: When I run code on OSX and it produces a stack trace, the output uses mangled symbols and is missing line numbers, like so - how can I change these stack traces to be more readable? [...] Use DMD master - support for line numbers in stack traces will be part of 2.081: More details: https://github.com/dlang/druntime/pull/2169 curl https://dlang.org/install.sh | bash -s dmd-nightly
Re: Stack traces with DMD on OSX
On Thursday, 31 May 2018 at 09:11:41 UTC, pineapple wrote: When I run code on OSX and it produces a stack trace, the output uses mangled symbols and is missing line numbers, like so - how can I change these stack traces to be more readable? 0 objectpool 0x000104e9a3bc _D4core7runtime18runModuleUnitTestsUZ19unittestSegvHandlerUNbNiiPS4core3sys5posix6signal9siginfo_tPvZv + 56 1 libsystem_platform.dylib0x7fff8bd5b5aa _sigtramp + 26 2 ??? 0x0002 0x0 + 2 3 objectpool 0x000104ea994b D2gc4impl12conservative2gc14ConservativeGC200__T9runLockedS79_D2gc4impl12conservative2gc14ConservativeGC12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS40_D2gc4impl12conservative2gc10mallocTimelS40_D2gc4impl12conservative2gc10numMallocslTmTkTmTxC8TypeInfoZ9runLockedMFNbKmKkKmKxC8TypeInfoZPv + 147 4 objectpool 0x000104ea3463 D2gc4impl12conservative2gc14ConservativeGC6qallocMFNbmkxC8TypeInfoZS4core6memory8BlkInfo_ + 115 5 objectpool 0x000104ea26a3 gc_qalloc + 51 6 objectpool 0x000104eaf5a8 D2rt8lifetime12__arrayAllocFNaNbmxC8TypeInfoxC8TypeInfoZS4core6memory8BlkInfo_ + 236 7 objectpool 0x000104eb3d9a _d_arrayliteralTX + 102 8 objectpool 0x000104cf7c2c D4mach3sys6memory19__unittestL120_1062FZv + 240 9 objectpool 0x0001049f8496 _D4mach3sys6memory9__modtestFZv + 14 10 objectpool 0x000104e9a409 D4core7runtime18runModuleUnitTestsUZ14__foreachbody2MFPS6object10ModuleInfoZi + 45 11 objectpool 0x000104e9067f D6object10ModuleInfo7opApplyFMDFPS6object10ModuleInfoZiZ9__lambda2MFyPS6object10ModuleInfoZi + 35 12 objectpool 0x000104eb5c56 D2rt5minfo17moduleinfos_applyFMDFyPS6object10ModuleInfoZiZ14__foreachbody2MFKS2rt19sections_osx_x86_6412SectionGroupZi + 86 13 objectpool 0x000104eb5be1 D2rt5minfo17moduleinfos_applyFMDFyPS6object10ModuleInfoZiZi + 33 14 objectpool 0x000104e90656 D6object10ModuleInfo7opApplyFMDFPS6object10ModuleInfoZiZi + 34 15 objectpool 0x000104e9a2f3 runModuleUnitTests + 127 16 objectpool 0x000104eaddc3 D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv + 23 17 objectpool 0x000104eadd5c D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv + 32 18 objectpool 0x000104eadcc7 _d_run_main + 459 19 objectpool 0x0001049f8caa main + 34 20 libdyld.dylib 0x7fff854835fd start + 1 Hello. feed "ddemangle" with the output.
Stack traces with DMD on OSX
When I run code on OSX and it produces a stack trace, the output uses mangled symbols and is missing line numbers, like so - how can I change these stack traces to be more readable? 0 objectpool 0x000104e9a3bc _D4core7runtime18runModuleUnitTestsUZ19unittestSegvHandlerUNbNiiPS4core3sys5posix6signal9siginfo_tPvZv + 56 1 libsystem_platform.dylib0x7fff8bd5b5aa _sigtramp + 26 2 ??? 0x0002 0x0 + 2 3 objectpool 0x000104ea994b D2gc4impl12conservative2gc14ConservativeGC200__T9runLockedS79_D2gc4impl12conservative2gc14ConservativeGC12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS40_D2gc4impl12conservative2gc10mallocTimelS40_D2gc4impl12conservative2gc10numMallocslTmTkTmTxC8TypeInfoZ9runLockedMFNbKmKkKmKxC8TypeInfoZPv + 147 4 objectpool 0x000104ea3463 D2gc4impl12conservative2gc14ConservativeGC6qallocMFNbmkxC8TypeInfoZS4core6memory8BlkInfo_ + 115 5 objectpool 0x000104ea26a3 gc_qalloc + 51 6 objectpool 0x000104eaf5a8 D2rt8lifetime12__arrayAllocFNaNbmxC8TypeInfoxC8TypeInfoZS4core6memory8BlkInfo_ + 236 7 objectpool 0x000104eb3d9a _d_arrayliteralTX + 102 8 objectpool 0x000104cf7c2c D4mach3sys6memory19__unittestL120_1062FZv + 240 9 objectpool 0x0001049f8496 _D4mach3sys6memory9__modtestFZv + 14 10 objectpool 0x000104e9a409 D4core7runtime18runModuleUnitTestsUZ14__foreachbody2MFPS6object10ModuleInfoZi + 45 11 objectpool 0x000104e9067f D6object10ModuleInfo7opApplyFMDFPS6object10ModuleInfoZiZ9__lambda2MFyPS6object10ModuleInfoZi + 35 12 objectpool 0x000104eb5c56 D2rt5minfo17moduleinfos_applyFMDFyPS6object10ModuleInfoZiZ14__foreachbody2MFKS2rt19sections_osx_x86_6412SectionGroupZi + 86 13 objectpool 0x000104eb5be1 D2rt5minfo17moduleinfos_applyFMDFyPS6object10ModuleInfoZiZi + 33 14 objectpool 0x000104e90656 D6object10ModuleInfo7opApplyFMDFPS6object10ModuleInfoZiZi + 34 15 objectpool 0x000104e9a2f3 runModuleUnitTests + 127 16 objectpool 0x000104eaddc3 D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv + 23 17 objectpool 0x000104eadd5c D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv + 32 18 objectpool 0x000104eadcc7 _d_run_main + 459 19 objectpool 0x0001049f8caa main + 34 20 libdyld.dylib 0x7fff854835fd start + 1
