12/18/2012 9:15 PM, Walter Bright пишет:
On 12/18/2012 8:48 AM, Dmitry Olshansky wrote:
After dropping debug info I can't yet make heads or tails of what's in
the exe
yet but it _seems_ to not include all of the unused code. Gotta
investigate on a
smaller sample.
Generate a linker .map file (-
On Wednesday, 19 December 2012 at 17:17:34 UTC, Dmitry Olshansky
wrote:
12/19/2012 1:33 AM, Walter Bright пишет:
On 12/18/2012 11:58 AM, Dmitry Olshansky wrote:
The same bytecode then could be be used for external
representation.
Sigh, there is (again) no point to an external bytecode.
BTW
12/19/2012 12:15 AM, Paulo Pinto пишет:
Am 18.12.2012 21:09, schrieb Dmitry Olshansky:
12/19/2012 12:01 AM, Jacob Carlborg пишет:
On 2012-12-18 17:48, Dmitry Olshansky wrote:
I'm using objconv by Agner Fog as I haven't got dumpobj (guess I'll buy
it if need be).
dumpobj is included in the D
12/19/2012 1:33 AM, Walter Bright пишет:
On 12/18/2012 11:58 AM, Dmitry Olshansky wrote:
The same bytecode then could be be used for external representation.
Sigh, there is (again) no point to an external bytecode.
BTW In the end I think I was convinced that bytecode won't buy D much.
Esp c
On Tuesday, 18 December 2012 at 17:30:41 UTC, Walter Bright wrote:
If I was doing it, and speed was paramount, I'd probably fix it
to generate native code instead of bytecode and so execute code
directly. Even simple JITs dramatically speeded up the early
Java VMs.
Could you re-use the compil
On 12/18/2012 11:26 AM, H. S. Teoh wrote:
Um, it does introduce major support costs for porting to different CPU
targets.
[...]
Could you elaborate?
Sure. You have to rewrite it when going from 32 to 64 bit code, or to ARM, or to
any other processor. It's not the same as the regular code gen
On 12/18/2012 11:58 AM, Dmitry Olshansky wrote:
The same bytecode then could be be used for external representation.
Sigh, there is (again) no point to an external bytecode.
On 12/18/2012 11:23 AM, H. S. Teoh wrote:
On Tue, Dec 18, 2012 at 09:55:57AM -0800, Walter Bright wrote:
On 12/18/2012 9:42 AM, H. S. Teoh wrote:
I was thinking more along the lines of things like fully automatic
purity, safety, exception inference. For example, every function body
eventually h
On 12/18/2012 08:26 PM, H. S. Teoh wrote:
On Tue, Dec 18, 2012 at 10:06:43AM -0800, Walter Bright wrote:
On 12/18/2012 9:49 AM, H. S. Teoh wrote:
Is it too late to change CTFE to work via native code?
No, because doing so involves zero language changes. It is purely a
quality-of-implementatio
Am 18.12.2012 21:09, schrieb Dmitry Olshansky:
12/19/2012 12:01 AM, Jacob Carlborg пишет:
On 2012-12-18 17:48, Dmitry Olshansky wrote:
I'm using objconv by Agner Fog as I haven't got dumpobj (guess I'll buy
it if need be).
dumpobj is included in the DMD release, at least on Mac OS X.
And l
12/19/2012 12:01 AM, Jacob Carlborg пишет:
On 2012-12-18 17:48, Dmitry Olshansky wrote:
I'm using objconv by Agner Fog as I haven't got dumpobj (guess I'll buy
it if need be).
dumpobj is included in the DMD release, at least on Mac OS X.
And linux has it. Guess Windows sucks ...
--
Dmitry
On 2012-12-18 17:48, Dmitry Olshansky wrote:
I'm using objconv by Agner Fog as I haven't got dumpobj (guess I'll buy
it if need be).
dumpobj is included in the DMD release, at least on Mac OS X.
--
/Jacob Carlborg
12/18/2012 9:30 PM, Walter Bright пишет:
On 12/18/2012 8:57 AM, Dmitry Olshansky wrote:
But adequate bytecode designed for interpreters (see e.g. Lua) are
designed for
faster execution. The way CTFE is done now* is a polymorphic call per
AST-node
that does a lot of analysis that could be decided
On Tue, Dec 18, 2012 at 10:06:43AM -0800, Walter Bright wrote:
> On 12/18/2012 9:49 AM, H. S. Teoh wrote:
> >Is it too late to change CTFE to work via native code?
>
> No, because doing so involves zero language changes. It is purely a
> quality-of-implementation issue.
Well, that much is obvious
On Tue, Dec 18, 2012 at 09:55:57AM -0800, Walter Bright wrote:
> On 12/18/2012 9:42 AM, H. S. Teoh wrote:
> >I was thinking more along the lines of things like fully automatic
> >purity, safety, exception inference. For example, every function body
> >eventually has to be processed by the compiler,
On 12/18/2012 9:49 AM, H. S. Teoh wrote:
Is it too late to change CTFE to work via native code?
No, because doing so involves zero language changes. It is purely a
quality-of-implementation issue.
Besides the
effort required to rework the existing code (and perhaps the
cross-compiling issue
On 12/18/2012 9:42 AM, H. S. Teoh wrote:
I was thinking more along the lines of things like fully automatic
purity, safety, exception inference. For example, every function body
eventually has to be processed by the compiler, so if a particular
function is inferred to throw exception X, for examp
On Tue, Dec 18, 2012 at 09:30:40AM -0800, Walter Bright wrote:
> On 12/18/2012 8:57 AM, Dmitry Olshansky wrote:
[...]
> >Another point is that pointer chasing data-structures is not a recipe
> >for fast repeated execution.
> >
> >To provide an analogy: executing calculation recursively on AST tree
On Tue, Dec 18, 2012 at 08:12:51AM -0800, Walter Bright wrote:
> On 12/18/2012 7:51 AM, H. S. Teoh wrote:
> >An idea occurred to me while reading this. What if, when compiling a
> >module, say, the compiler not only emits object code, but also
> >information like which functions are implied to be s
On 12/18/2012 8:57 AM, Dmitry Olshansky wrote:
But adequate bytecode designed for interpreters (see e.g. Lua) are designed for
faster execution. The way CTFE is done now* is a polymorphic call per AST-node
that does a lot of analysis that could be decided once and stored in ... *ehm*
... IR. Curr
On 12/18/2012 8:54 AM, Andrei Alexandrescu wrote:
On 12/18/12 10:01 AM, Walter Bright wrote:
On 12/18/2012 1:43 AM, Dmitry Olshansky wrote:
Compared to doing computations on AST tries (and looking up every name
in symbol
table?), creating fake nodes when the result is computed etc?
CTFE does
On 12/18/2012 8:48 AM, Dmitry Olshansky wrote:
After dropping debug info I can't yet make heads or tails of what's in the exe
yet but it _seems_ to not include all of the unused code. Gotta investigate on a
smaller sample.
Generate a linker .map file (-map to dmd). That'll tell you what's in it
12/18/2012 7:01 PM, Walter Bright пишет:
On 12/18/2012 1:43 AM, Dmitry Olshansky wrote:
Compared to doing computations on AST tries (and looking up every name
in symbol
table?), creating fake nodes when the result is computed etc?
CTFE does not look up every (or any) name in the symbol table.
On 12/18/12 10:01 AM, Walter Bright wrote:
On 12/18/2012 1:43 AM, Dmitry Olshansky wrote:
Compared to doing computations on AST tries (and looking up every name
in symbol
table?), creating fake nodes when the result is computed etc?
CTFE does not look up every (or any) name in the symbol table
12/18/2012 6:51 PM, Walter Bright пишет:
On 12/18/2012 1:33 AM, Dmitry Olshansky wrote:
More then that - the end result is the same: to avoid carrying junk
into an app
you (or compiler) still have to put each function in its own section.
That's what COMDATs are.
Okay..
Doing separate compi
On 12/18/2012 7:51 AM, H. S. Teoh wrote:
An idea occurred to me while reading this. What if, when compiling a
module, say, the compiler not only emits object code, but also
information like which functions are implied to be strongly pure, weakly
pure, @safe, etc., as well as some kind of symbol d
On Tue, Dec 18, 2012 at 07:01:28AM -0800, Walter Bright wrote:
> On 12/18/2012 1:43 AM, Dmitry Olshansky wrote:
> >Compared to doing computations on AST tries (and looking up every
> >name in symbol table?), creating fake nodes when the result is
> >computed etc?
>
> CTFE does not look up every (o
On Tue, Dec 18, 2012 at 06:55:34AM -0800, Walter Bright wrote:
> On 12/18/2012 3:43 AM, foobar wrote:
> >Honest question - If D already has all the semantic info in COMDAT
> >sections,
>
> It doesn't. COMDATs are object file sections. They do not contain
> type info, for example.
>
> > * provide
On 12/18/2012 1:43 AM, Dmitry Olshansky wrote:
Compared to doing computations on AST tries (and looking up every name in symbol
table?), creating fake nodes when the result is computed etc?
CTFE does not look up every (or any) name in the symbol table. I don't see any
advantage to interpreting
On 12/18/2012 3:43 AM, foobar wrote:
Honest question - If D already has all the semantic info in COMDAT sections,
It doesn't. COMDATs are object file sections. They do not contain type info, for
example.
* provide a byte-code solution to support the portability case. e.g Java
byte-code or
On 12/18/2012 1:33 AM, Dmitry Olshansky wrote:
More then that - the end result is the same: to avoid carrying junk into an app
you (or compiler) still have to put each function in its own section.
That's what COMDATs are.
Doing separate compilation I always (unless doing LTO or template heavy
On Tuesday, 18 December 2012 at 11:43:18 UTC, foobar wrote:
On Monday, 17 December 2012 at 22:24:00 UTC, Walter Bright
wrote:
On 12/17/2012 2:08 PM, Dmitry Olshansky wrote:
I really loved the way Turbo Pascal units were made. I wish D
go the same
route. Object files would then be looked at as
On 12/18/12, foobar wrote:
> Besides, the other compilers merge in the same front-end
> code so they'll gain the same feature anyway. There's no gain in
> separating it out to rdmd.
Adding more front-end features adds more work for maintainers of
compilers which are based on the DMD front-end, an
On Tuesday, 18 December 2012 at 00:48:40 UTC, Walter Bright wrote:
Wow, I think that's exactly what we could use! It serves
multiple optional use
cases all at once!
Was there a technical reason for you not getting around
towards implementing, or
just a lack of time?
There always seemed som
On Monday, 17 December 2012 at 22:24:00 UTC, Walter Bright wrote:
On 12/17/2012 2:08 PM, Dmitry Olshansky wrote:
I really loved the way Turbo Pascal units were made. I wish D
go the same
route. Object files would then be looked at as minimal and
stupid variation of
module where symbols are ide
On Tuesday, 18 December 2012 at 00:15:04 UTC, H. S. Teoh wrote:
On Tue, Dec 18, 2012 at 02:08:55AM +0400, Dmitry Olshansky
wrote:
[...]
I suspect it's one of prime examples where UNIX philosophy of
combining a bunch of simple (~ dumb) programs together in
place of
one more complex program was
12/18/2012 4:42 AM, Walter Bright пишет:
On 12/17/2012 3:03 PM, deadalnix wrote:
I know that. I not arguing against that. I'm arguing against the fact
that this
is a blocker. This is blocker in very few use cases in fact. I just
look at the
whole picture here. People needing that are the excepti
12/18/2012 2:23 AM, Walter Bright пишет:
On 12/17/2012 2:08 PM, Dmitry Olshansky wrote:
I really loved the way Turbo Pascal units were made. I wish D go the same
route. Object files would then be looked at as minimal and stupid
variation of
module where symbols are identified by mangling (not p
On Tuesday, 18 December 2012 at 07:48:01 UTC, Jacob Carlborg
wrote:
On 2012-12-17 23:12, Walter Bright wrote:
I have toyed with the idea many times, however, of having dmd
support
zip files. Zip files can contain an arbitrary file hierarchy,
with
individual files in compressed, encrypted, or p
On 12/17/2012 11:40 PM, Jacob Carlborg wrote:
On 2012-12-17 00:09, Walter Bright wrote:
Figure out the cases where it happens and fix those cases.
How is it supposed to work? Could there be some issue with the dependency
tracker that should otherwise have indicated that more modules should ha
On 2012-12-17 23:12, Walter Bright wrote:
I have toyed with the idea many times, however, of having dmd support
zip files. Zip files can contain an arbitrary file hierarchy, with
individual files in compressed, encrypted, or plaintext at the selection
of the zip builder. An entire project, or li
On 2012-12-17 00:09, Walter Bright wrote:
Figure out the cases where it happens and fix those cases.
How is it supposed to work? Could there be some issue with the
dependency tracker that should otherwise have indicated that more
modules should have been recompiled.
--
/Jacob Carlborg
On 2012-12-18 01:13, H. S. Teoh wrote:
The problem is not so much the structure preprocessor -> compiler ->
assembler -> linker; the problem is that these logical stages have been
arbitrarily assigned to individual processes residing in their own
address space, communicating via files (or pipes,
On 12/17/12 6:11 PM, Rob T wrote:
On Monday, 17 December 2012 at 22:12:01 UTC, Walter Bright wrote:
dmd xx foo.zip
is equivalent to:
unzip foo
dmd xx a.d b/c.d d.obj
P.S. I've also wanted to use .zip files as the .lib file format (!),
as the various .lib formats have nothing over .zip files.
On Tuesday, 18 December 2012 at 02:48:05 UTC, Walter Bright wrote:
Using standard zip tools is a big plus.
Yes, but why limit yourself in this way?
The easy answer is look at the problems stemming from dmd using
an object file format on Win32 that nobody else uses.
I definitely didn't say
On Mon, 17 Dec 2012 00:19:51 -0800, deadalnix wrote:
On Monday, 17 December 2012 at 08:02:12 UTC, Adam Wilson wrote:
With respect to those who hold one ideology above others, trying to
impose those ideals on another is a great way to ensure animosity. What
a business does with their code is
On Tuesday, 18 December 2012 at 02:48:05 UTC, Walter Bright wrote:
Using standard zip tools is a big plus.
Yes, but why limit yourself in this way?
The easy answer is look at the problems stemming from dmd using
an object file format on Win32 that nobody else uses.
I didn't say dmd should
On 12/17/2012 6:40 PM, Rob T wrote:
On Tuesday, 18 December 2012 at 02:17:25 UTC, Walter Bright wrote:
On 12/17/2012 6:13 PM, Rob T wrote:
Your suggestion concerning the use of zip files is a good idea, although you
mention the encryption algo is very weak, but is there any reason to use a weak
On Tuesday, 18 December 2012 at 02:17:25 UTC, Walter Bright wrote:
On 12/17/2012 6:13 PM, Rob T wrote:
Your suggestion concerning the use of zip files is a good
idea, although you
mention the encryption algo is very weak, but is there any
reason to use a weak
encryption algo, and is there even
3) Performance can be improved to (near) native speeds with a
JIT
compiler. But then you might as well as go native to begin
with. Why
wait till runtime to do compilation, when it can be done
beforehand?
The point though is that with a JIT, you can transmit source code
(or byte code which is
On 12/17/2012 6:13 PM, Rob T wrote:
Your suggestion concerning the use of zip files is a good idea, although you
mention the encryption algo is very weak, but is there any reason to use a weak
encryption algo, and is there even a reason to bother maintaining compatibility
with the common zip form
On Tuesday, 18 December 2012 at 01:52:21 UTC, Walter Bright wrote:
If we implement a way of "hiding" implementation details that
*allows*
CTFE and templates (and thus one up the C++ situation), this
will create
a stronger incentive for D adoption. It doesn't matter if it's
not hard
to "unhide"
On 12/17/2012 5:40 PM, Simen Kjaeraas wrote:
.zip already has encryption,
Just for the record, zip file "encryption" is trivially broken, and there are
free downloadable tools to do that.
About all it will do is keep your kid sister from reading your diary.
On 12/17/2012 5:28 PM, H. S. Teoh wrote:
Using PIMPL only helps if you're trying to hide implementation details
of a struct or class. Anything that requires CTFE is out of the
question. Templates are out of the question (this was also true with
C++). This reduces the incentive to adopt D, since t
On Tuesday, 18 December 2012 at 01:30:22 UTC, H. S. Teoh wrote:
If we implement a way of "hiding" implementation details that
*allows*
CTFE and templates (and thus one up the C++ situation), this
will create
a stronger incentive for D adoption. It doesn't matter if it's
not hard
to "unhide" t
On 2012-12-18, 02:28, H. S. Teoh wrote:
If we implement a way of "hiding" implementation details that *allows*
CTFE and templates (and thus one up the C++ situation), this will create
a stronger incentive for D adoption. It doesn't matter if it's not hard
to "unhide" the implementation; we don't
On Mon, Dec 17, 2012 at 04:42:13PM -0800, Walter Bright wrote:
> On 12/17/2012 3:03 PM, deadalnix wrote:
[...]
> >And what prevent us from using a bytecode that loose information ?
>
> I'd turn that around and ask why have a bytecode?
>
>
> >As long as it is CTFEable, most people will be happy.
On 12/17/2012 4:47 PM, deadalnix wrote:
On Tuesday, 18 December 2012 at 00:42:13 UTC, Walter Bright wrote:
On 12/17/2012 3:03 PM, deadalnix wrote:
I know that. I not arguing against that. I'm arguing against the fact that this
is a blocker. This is blocker in very few use cases in fact. I just
On 12/17/2012 3:27 PM, Denis Koroskin wrote:
On Mon, 17 Dec 2012 13:47:36 -0800, Walter Bright
wrote:
I've often thought Java bytecode was a complete joke. It doesn't deliver any
of its promises. You could tokenize Java source code, run the result through
an lzw compressor, and get the equival
On 12/17/2012 3:11 PM, Rob T wrote:
I suspect most file transport protocols already compress the data, so
compressing it ourselves probably accomplishes nothing. There are also
compressed filesystems, so storing files in a compressed manner likely
accomplishes little.
Yes however my understandi
On Tuesday, 18 December 2012 at 00:42:13 UTC, Walter Bright wrote:
On 12/17/2012 3:03 PM, deadalnix wrote:
I know that. I not arguing against that. I'm arguing against
the fact that this
is a blocker. This is blocker in very few use cases in fact. I
just look at the
whole picture here. People n
On 12/17/2012 3:03 PM, deadalnix wrote:
I know that. I not arguing against that. I'm arguing against the fact that this
is a blocker. This is blocker in very few use cases in fact. I just look at the
whole picture here. People needing that are the exception, not the rule.
I'm not sure what you
On Tue, Dec 18, 2012 at 02:08:55AM +0400, Dmitry Olshansky wrote:
[...]
> I suspect it's one of prime examples where UNIX philosophy of
> combining a bunch of simple (~ dumb) programs together in place of
> one more complex program was taken *far* beyond reasonable lengths.
>
> Having a pipe-line:
On Mon, 17 Dec 2012 13:47:36 -0800, Walter Bright
wrote:
I've often thought Java bytecode was a complete joke. It doesn't deliver
any of its promises. You could tokenize Java source code, run the result
through an lzw compressor, and get the equivalent functionality in every
way.
Not
Am 17.12.2012 23:23, schrieb Walter Bright:
On 12/17/2012 2:08 PM, Dmitry Olshansky wrote:
I really loved the way Turbo Pascal units were made. I wish D go the same
route. Object files would then be looked at as minimal and stupid
variation of
module where symbols are identified by mangling (no
On Monday, 17 December 2012 at 22:12:01 UTC, Walter Bright wrote:
On 12/17/2012 1:53 PM, Rob T wrote:
I mentioned in a previous post that we should perhaps focus on
making the .di
concept more efficient rather than focus on obfuscation.
We're not going to do obfuscation, because as I explaine
On Monday, 17 December 2012 at 21:36:46 UTC, Walter Bright wrote:
On 12/17/2012 12:49 PM, deadalnix wrote:
Granted, this is still easier than assembly, but you neglected
the fact that
java is rather simple, where D isn't. It is unlikely that an
optimized D
bytecode can ever be decompiled in a
On Monday, 17 December 2012 at 22:12:01 UTC, Walter Bright wrote:
On 12/17/2012 1:53 PM, Rob T wrote:
I mentioned in a previous post that we should perhaps focus on
making the .di
concept more efficient rather than focus on obfuscation.
We're not going to do obfuscation, because as I explaine
On 12/17/2012 2:08 PM, Dmitry Olshansky wrote:
I really loved the way Turbo Pascal units were made. I wish D go the same
route. Object files would then be looked at as minimal and stupid variation of
module where symbols are identified by mangling (not plain meta data as (would
be) in module) an
Walter Bright:
dmd foo.zip
or:
dmd myfile ThirdPartyLib.zip
and have it work. The advantage here is simply that everything
can be contained in one simple file.
This was discussed a lot of time ago (even using a "rock" suffix
for those zip files) and it seems a nice idea.
Bye,
bear
On 12/17/12, Walter Bright wrote:
> I have toyed with the idea many times, however, of having dmd support zip
> files.
I think such a feature is better suited for RDMD. Then many other
compilers would benefit, since RDMD can be used with GDC and LDC.
On 12/17/2012 1:53 PM, Rob T wrote:
I mentioned in a previous post that we should perhaps focus on making the .di
concept more efficient rather than focus on obfuscation.
We're not going to do obfuscation, because as I explained such cannot work, and
we shouldn't do a disservice to users by pr
12/18/2012 12:34 AM, Paulo Pinto пишет:
Am 17.12.2012 21:09, schrieb foobar:
On Monday, 17 December 2012 at 04:49:46 UTC, Michel Fortin wrote:
On 2012-12-17 03:18:45 +, Walter Bright
said:
Whether the file format is text or binary does not make any
fundamental difference.
I too expect
On Monday, 17 December 2012 at 21:47:36 UTC, Walter Bright wrote:
There is no substantive difference between bytecode and source
code, as I've been trying to explain. It is not superior in any
way, (other than being shorter, and hence less costly to
transmit over the internet).
I mentione
On 12/17/2012 12:51 PM, deadalnix wrote:
On Monday, 17 December 2012 at 09:40:22 UTC, Walter Bright wrote:
On 12/17/2012 12:54 AM, deadalnix wrote:
More seriously, I understand that in some cases, di are interesting. Mostly if
you want to provide a closed source library to be used by 3rd party
On Monday, 17 December 2012 at 12:54:46 UTC, jerro wrote:
If we want to allow D to fit into various niche markets
overlooked by C++, for added security, encryption could be
added, where the person compiling encrypted .di files would
have to supply a key. That would work only for certain
situat
On 12/17/2012 12:49 PM, deadalnix wrote:
Granted, this is still easier than assembly, but you neglected the fact that
java is rather simple, where D isn't. It is unlikely that an optimized D
bytecode can ever be decompiled in a satisfying way.
Please listen to me.
You have FULL TYPE INFORMATIO
On Monday, 17 December 2012 at 20:31:08 UTC, Paulo Pinto wrote:
But if there was interest, I am sure there could be a way to
store the
template information in the compiled module, while exposing the
required type parameters for the template in the .di file, a la
Ada.
--
Paulo
Maybe the focu
On Monday, 17 December 2012 at 09:40:22 UTC, Walter Bright wrote:
On 12/17/2012 12:54 AM, deadalnix wrote:
More seriously, I understand that in some cases, di are
interesting. Mostly if
you want to provide a closed source library to be used by 3rd
party devs.
You're missing another major use
On Monday, 17 December 2012 at 09:37:48 UTC, Walter Bright wrote:
On 12/17/2012 12:55 AM, Paulo Pinto wrote:
Assembly is no different than reversing any other type of
bytecode:
This is simply not true for Java bytecode.
About the only thing you lose with Java bytecode are local
variable name
Am 16.12.2012 23:32, schrieb Andrej Mitrovic:
On 12/16/12, Paulo Pinto wrote:
If modules are used correctly, a .di should be created with the public
interface and everything else is already in binary format, thus the
compiler is not really parsing everything all the time.
A lot of D code tend
Am 17.12.2012 21:09, schrieb foobar:
On Monday, 17 December 2012 at 04:49:46 UTC, Michel Fortin wrote:
On 2012-12-17 03:18:45 +, Walter Bright
said:
Whether the file format is text or binary does not make any
fundamental difference.
I too expect the difference in performance to be negli
On Monday, 17 December 2012 at 04:49:46 UTC, Michel Fortin wrote:
On 2012-12-17 03:18:45 +, Walter Bright
said:
Whether the file format is text or binary does not make any
fundamental difference.
I too expect the difference in performance to be negligible in
binary form if you maintain
On 2012-12-17 16:01, Walter Bright wrote:
Yup. I'd be very surprised if they were based on decompiled Windows
executables.
Not only that, I didn't say decompiling by hand was impossible. I
repeatedly said that it can be done by an expert with a lot of patience.
But not automatically. Java .cla
On 12/17/2012 3:02 AM, mist wrote:
AFAIK those are more like Windows API & ABI reverse engineered and reimplemented
and that is a huge difference.
Yup. I'd be very surprised if they were based on decompiled Windows executables.
Not only that, I didn't say decompiling by hand was impossible. I
On 12/17/2012 4:38 AM, Jacob Carlborg wrote:> On 2012-12-17 10:58, Walter Bright
wrote:
>
>> Google "convert object file to C"
>
> A few seconds on Google resulted in this:
>
> http://www.hex-rays.com/products/decompiler/index.shtml
>
hex-rays is an interactive tool. It's "decompile" to things l
On 2012-12-17 12:20, eles wrote:
I don't know about such frameworks, but the idea that these kind of
files should be handled by the compiler, not by the operating system.
They are not meant to be applications, but libraries.
They are handled by the compiler. GCC has the -framework flag.
https
It's not as if phobos would be distributed that way. And even
it if was,
then there'd be an uproar and a fork of the project.
I don't think that the FSF would be to happy about adding a front
end with DRM support to GCC, even if no encrypted libraries would
be added along with it. Of course
On 17 December 2012 12:54, jerro wrote:
> If we want to allow D to fit into various niche markets overlooked by C++,
>> for added security, encryption could be added, where the person compiling
>> encrypted .di files would have to supply a key. That would work only for
>> certain situations, not
If we want to allow D to fit into various niche markets
overlooked by C++, for added security, encryption could be
added, where the person compiling encrypted .di files would
have to supply a key. That would work only for certain
situations, not for mass distribution, but it may be useful to
e
On 2012-12-17 10:58, Walter Bright wrote:
Google "convert object file to C"
A few seconds on Google resulted in this:
http://www.hex-rays.com/products/decompiler/index.shtml
--
/Jacob Carlborg
On Monday, 17 December 2012 at 09:58:28 UTC, Walter Bright wrote:
On 12/17/2012 1:35 AM, Paulo Pinto wrote:
It suffices to get the general algorithm behind the code, and
that is impossible
to hide, unless the developer resorts to cryptography.
I'll say again, with enough effort, an expert *ca
Sounds a lot like frameworks and other type of bundles on Mac
OS X. A framework is a folder, with the .framework extension,
containing a dynamic library, header files and all other
necessary resource files like images and so on.
I don't know about such frameworks, but the idea that these kind
AFAIK those are more like Windows API & ABI reverse engineered
and reimplemented and that is a huge difference.
On Monday, 17 December 2012 at 10:01:35 UTC, Jacob Carlborg wrote:
On 2012-12-17 09:21, Walter Bright wrote:
I know what I'm talking about with this. The only time they
get reverse
On 2012-12-17 10:13, eles wrote:
WRT to all opinions above (ie: binary vs text, what to put etc.)
I had some reflection on that some time ago: how about bundling a
"header" file (that would be the .di file) and a binary file (the
compiled .d file, that is the .obj file) into a single .zip (albe
On 17 December 2012 09:29, Walter Bright wrote:
> On 12/17/2012 1:15 AM, Paulo Pinto wrote:
>
>> http://www.hopperapp.com/
>>
>> I really like the way it generates pseudo-code and basic block graphs out
>> of
>> instruction sequences.
>>
>
> I looked at their examples. Sorry, that's just step one
On 2012-12-17 09:21, Walter Bright wrote:
I know what I'm talking about with this. The only time they get reverse
engineered is when somebody really really REALLY wants to do it, an
expert is necessary to do the job, and it's completely impractical for
larger sets of files. You cannot build a to
On 2012-12-17 09:19, deadalnix wrote:
I can't stop myself laughing at people that may think any business can
be based on java, PHP or C#. That is a mere dream ! Such technology will
simply never get used in companies, because bytecode can be decoded !
Yet there are a lot of business that are b
On 12/17/2012 1:35 AM, Paulo Pinto wrote:
It suffices to get the general algorithm behind the code, and that is impossible
to hide, unless the developer resorts to cryptography.
I'll say again, with enough effort, an expert *can* decompile object files by
hand. You can't make a tool to do that
On 12/17/2012 1:45 AM, Paulo Pinto wrote:
Pencil and paper?
Yes, as I wrote, you can reverse engineer object files, instruction by
instruction, by an expert with pencil and paper.
You can't make a tool to do it automatically.
You *can* make such a tool for Java bytecode files, and such free
1 - 100 of 185 matches
Mail list logo
