I've made a few updates based on some of the feedback in this
thread.
- execute() renamed to query()
- query with input binds directly from connection
- query() returns result for chaining
The design is still early stage. I've got a growing list of
design options which I'll bring into
On Sunday, 6 March 2016 at 08:53:05 UTC, Kagamin wrote:
On Saturday, 5 March 2016 at 18:00:56 UTC, Erik Smith wrote:
I'm definitely going to start working in async capability (or
more accurately, non-blocking) into the interface.
Huh? Non-blocking operation is not reflected in interface. Only
On Saturday, 5 March 2016 at 18:00:56 UTC, Erik Smith wrote:
I'm definitely going to start working in async capability (or
more accurately, non-blocking) into the interface.
Huh? Non-blocking operation is not reflected in interface. Only
asynchronous requires special interface. Vibe
On 2016-03-05 19:00, Erik Smith wrote:
I'm definitely going to start working in async capability (or more
accurately, non-blocking) into the interface. Both models are
essential and there are strong use cases for both, but I know there is a
lot of interest in NBIO for vibe.d compatibility.
On Saturday, 5 March 2016 at 13:13:09 UTC, Jacob Carlborg wrote:
On 2016-03-05 11:23, Saurabh Das wrote:
A little late to the party, nevertheless: Thanks for doing
this, it will
be super-helpful!
My only feature request will be: please make it work with
minimal effort
with Vibe.D! :)
On 2016-03-05 11:23, Saurabh Das wrote:
A little late to the party, nevertheless: Thanks for doing this, it will
be super-helpful!
My only feature request will be: please make it work with minimal effort
with Vibe.D! :)
Yeah, that's really important. Unfortunately it looks like a
On Tuesday, 1 March 2016 at 21:00:30 UTC, Erik Smith wrote:
I'm back to actively working on a std.database specification &
implementation. It's still unstable, minimally tested, and
there is plenty of work to do, but I wanted to share an update
on my progress.
[...]
A little
On Friday, 4 March 2016 at 23:55:55 UTC, Erik Smith wrote:
I think some basic object serialization capabilities would be
great although I'm not sure how the bare names can be accessed
like that through the rowSet How would that work?
I did a project a while back using mysql-native (see
On Friday, 4 March 2016 at 22:44:24 UTC, Sebastiaan Koppe wrote:
On Friday, 4 March 2016 at 18:42:45 UTC, Erik Smith wrote:
auto db = createDatabase("file:///testdb");
auto rowSet = db.connection().statement("select name,score
from score").execute;
foreach (r; rowSet)
On Friday, 4 March 2016 at 18:42:45 UTC, Erik Smith wrote:
auto db = createDatabase("file:///testdb");
auto rowSet = db.connection().statement("select name,score
from score").execute;
foreach (r; rowSet) writeln(r[0].as!string,",",r[1].as!int);
You'll want to have some types in
On Friday, 4 March 2016 at 16:41:35 UTC, Chris Wright wrote:
With embedded databases, there's a lot of variety out there,
probably a decent selection of tradeoffs, so I'm not sure any
one would be appropriate to phobos.
The one written from scratch specially for D (I'm talking in
general,
On Friday, 4 March 2016 at 16:54:33 UTC, Kagamin wrote:
On Thursday, 3 March 2016 at 17:46:02 UTC, Erik Smith wrote:
BTW in the oracle driver you use that ODBC idiom of passing
strings as pointer+length pairs. Why don't you use it in ODBC
driver?
That will be fixed in the next push.
erik
rowSet)
writeln(r[0].as!string,",",r[1].as!int);
I'll track query as an alternative name for execute() and
std.sql as alternative for std.database.
Why not only:
auto rowSet = db.connection().query("select name,scorefrom
score");
Or instead of query maybe "returnRows&q
track query as an alternative name for execute() and
std.sql as alternative for std.database.
Why not only:
auto rowSet = db.connection().query("select name,scorefrom
score");
Or instead of query maybe "returnRows" or just "rows", I think
the other way is too verbose.
Bubba.
o rowSet = db.connection().statement("select name,score
from score").execute;
foreach (r; rowSet) writeln(r[0].as!string,",",r[1].as!int);
I'll track query as an alternative name for execute() and std.sql
as alternative for std.database.
On Thursday, 3 March 2016 at 17:46:02 UTC, Erik Smith wrote:
The only leverage I might have is a lot of familiarity working
with many of the native C client interfaces and experience
implementing higher level interfaces on top. That and is also
a lot of existing work to draw on that can
On Friday, 4 March 2016 at 14:44:48 UTC, Erik Smith wrote:
Actually I like this and I think it can work. I'm trying to
keep a single execute function name for both row/no-row
queries. I can still return the range proxy for no-row queries
that is either empty or throws on access.
Yes, that's
On Fri, 04 Mar 2016 06:16:59 +, Piotrek wrote:
> For client-server approach I agree with the above. For embedded design
> (as in my project) this is not a case.
Which is all I'm saying. Something in std.database sounds like it should
allow you to interact with databases, lik
On Friday, 4 March 2016 at 11:57:49 UTC, Kagamin wrote:
On Thursday, 3 March 2016 at 18:08:26 UTC, Erik Smith wrote:
db.execute("select from t").reader; //row range
db.execute("select from t").get!long; //scalar
db.execute("select from t"); //non-query
More good options (the 3rd one is
On Thursday, 3 March 2016 at 18:08:26 UTC, Erik Smith wrote:
db.execute("select from t").reader; //row range
db.execute("select from t").get!long; //scalar
db.execute("select from t"); //non-query
More good options (the 3rd one is there). Also at the value
access level there are several
On Thursday, 3 March 2016 at 18:48:08 UTC, Chris Wright wrote:
You were a bit vague before. I interpreted you as saying "just
offer a range and an array-like API, and then you can use it
with std.algorithm". But if you meant to offer an API that is
similar to std.algorithm and also array-like,
On Thu, 03 Mar 2016 15:50:04 +, Piotrek wrote:
> On Thursday, 3 March 2016 at 01:49:22 UTC, Chris Wright wrote:
>> If you're trying to connect to a SQL database or a document database,
>> as I'd expect for something called "std.database"
>
> The thing is I st
On Thursday, 3 March 2016 at 17:03:58 UTC, Kagamin wrote:
On Thursday, 3 March 2016 at 15:53:28 UTC, Erik Smith wrote:
auto r = db.connection().statement("select from t").range();
// nouns
db.execute("select from t").range();
`range` is probably ok.
Or
auto connection =
On Thursday, 3 March 2016 at 16:08:03 UTC, Piotrek wrote:
I agree with you we need database manipulation in Phobos.
However modules like db, gui, xml or similar are too much work
for a one developer. And as you can see from time to time there
apears someone with its own vision.
That's why,
On the other hand execute can simply return the reader with extra
getter for scalar result. Just don't do stuff until it's
iterated. Is it possible?
auto rows = db.execute("select * from t");
Other options:
db.execute("select from t").reader; //row range
db.execute("select from t").get!long; //scalar
db.execute("select from t"); //non-query
On Thursday, 3 March 2016 at 15:53:28 UTC, Erik Smith wrote:
auto r = db.connection().statement("select from t").range();
// nouns
db.execute("select from t").range();
`range` is probably ok.
Or
auto connection = db.createConnection();
connection.execute("select from t").range();
auto r =
On Wednesday, 2 March 2016 at 17:13:32 UTC, Erik Smith wrote:
There are a number of areas where this design is an improvement
over DDBC: ease-of-use, better resource management (no scope,
no GC), phobos compatibility, to name a few. There is a lot
more that needs to be added to make it
On Thursday, 3 March 2016 at 11:16:03 UTC, Dejan Lekic wrote:
On Tuesday, 1 March 2016 at 21:00:30 UTC, Erik Smith wrote:
I'm back to actively working on a std.database specification &
implementation. It's still unstable, minimally tested, and
there is plenty of work to do, but I wa
On Thursday, 3 March 2016 at 15:07:43 UTC, Kagamin wrote:
Also member names: methods are named after verbs, you use
nouns. Method `next` is ambiguous: is the first row the next
row? `fetch` or `fetchRow` would be better.
Those are actually internal methods not intended for the
interface
On Thursday, 3 March 2016 at 01:49:22 UTC, Chris Wright wrote:
If you're trying to connect to a SQL database or a document
database, as I'd expect for something called "std.database"
The thing is I strongly encourage to not reserve std.database for
external database clients and
Also member names: methods are named after verbs, you use nouns.
Method `next` is ambiguous: is the first row the next row?
`fetch` or `fetchRow` would be better.
I suggest you call the package stdx.db - it is not (and may not
become) a standard package, so `std` is out of question. If it
is supposed to be *proposed* as standard package, then `stdx`
is good because that is what some people have used in the past
(while others used the ugly
On Tuesday, 1 March 2016 at 21:00:30 UTC, Erik Smith wrote:
I'm back to actively working on a std.database specification &
implementation. It's still unstable, minimally tested, and
there is plenty of work to do, but I wanted to share an update
on my progress.
I suggest you call the pac
On 03/03/16 8:36 AM, landaire wrote:
On Wednesday, 2 March 2016 at 18:28:34 UTC, landaire wrote:
How is this a UAF? Isn't the struct copied?
Ah I think I misunderstood. You mean in the database, not the dpaste?
Correct. My code was just to showcase the problem.
array rather than a key/value collection -- and that's a decent start.
If you're trying to connect to a SQL database or a document database, as
I'd expect for something called "std.database", it's a pretty terrible
API:
* No index scans, lookups, or range queries.
* No suppo
On Wednesday, 2 March 2016 at 15:41:56 UTC, Piotrek wrote:
Moreover one may say it's almost impossible to make a common
and effective interface which would work with all databases.
e.g. someone on Wikipedia argues ODBC is obolete (check "ODBC
today")
I believe that section is about PHP
On Wednesday, 2 March 2016 at 18:28:34 UTC, landaire wrote:
How is this a UAF? Isn't the struct copied?
Ah I think I misunderstood. You mean in the database, not the
dpaste?
On Wednesday, 2 March 2016 at 03:07:54 UTC, Rikki Cattermole
wrote:
Okay I've found a problem.
Here is some code demonstrating it.
http://dpaste.dzfl.pl/022c9e610a18
Now take a look again at Database
https://github.com/cruisercoder/dstddb/blob/master/src/std/database/poly/database.d#L37
Do
On Wednesday, 2 March 2016 at 15:41:56 UTC, Piotrek wrote:
On Tuesday, 1 March 2016 at 21:00:30 UTC, Erik Smith wrote:
[...]
My quick comments:
1. In my opinion it should not be called std.database, but
let's say "std.dbc".
This is because it looks like a wrapper over db clients.
1. In my opinion it should not be called std.database, but
let's say "std.dbc".
This is because it looks like a wrapper over db clients.
Moreover one may say it's almost impossible to make a common
and effective interface which would work with all databases.
e.g. someone on Wikipe
(by using templates) while
this issue is sorted out.
My quick comments:
1. In my opinion it should not be called std.database, but let's
say "std.dbc".
This is because it looks like a wrapper over db clients.
Moreover one may say it's almost impossible to make a common and
effective
I will look at your managed approach to understand it better.
One drawback I can think of is that destruction might not occur
immediately. This can be an issue for shared libraries when the
GC hasn't run when the library call returns to the host
application.
Maybe it's a C++ bias, but the
On 02/03/16 4:48 PM, Erik Smith wrote:
Yes agree that the poly Database is broken - it isn't reference counted
and I will fix that.
My point was, you shouldn't handle that.
Your sample code had me wondering if I am missing something else, but I
can't see another issue yet. I think the use
Yes agree that the poly Database is broken - it isn't reference
counted and I will fix that.
Your sample code had me wondering if I am missing something else,
but I can't see another issue yet. I think the use of classes
would definitely lead to problems with resources being freed out
of
Hi Stefan,
It might be a challenge for CTFE compatibility in the API, but it
would be interesting to see how much of it is workable. There
does need to be some optional API elements in cases where it's
not supported by the underlying database client(array binding for
example) and these
Okay I've found a problem.
Here is some code demonstrating it.
http://dpaste.dzfl.pl/022c9e610a18
Now take a look again at Database
https://github.com/cruisercoder/dstddb/blob/master/src/std/database/poly/database.d#L37
Do you see the problem?
The solution is simple.
The client database
On Tuesday, 1 March 2016 at 21:00:30 UTC, Erik Smith wrote:
I'm back to actively working on a std.database specification &
implementation. It's still unstable, minimally tested, and
there is plenty of work to do, but I wanted to share an update
on my progress.
[...]
Hi Erik,
As
Typo fixed - thanks. Incidentally, I'm not 100% content with
createDatabase. With the library being template based, the types
are no longer as easy to work with directly:
auto database = Database!DefaultPolicy();
alias cant be used because it instantiates. The template
argument can be
On Tuesday, 1 March 2016 at 21:00:30 UTC, Erik Smith wrote:
Please feel free to comment or question on the design as
evolves.
Minor typo in the fluent style select section of readme.md.
the line
createDatabase("file:///demo.sqlite");
should be
createDatabase("file:///demo.sqlite")
I'm back to actively working on a std.database specification &
implementation. It's still unstable, minimally tested, and there
is plenty of work to do, but I wanted to share an update on my
progress.
The main focus of this project is to bring a standard interface
for database cli
On 2015-05-28 06:57, Robert burner Schadek wrote:
struct Table;
Table a, b, c;
con.insert!Table(a);
...
if you use CTFE to create the statement string there is no reason to
reuse it.
it will be string literal, that's even better! Think Big. Think D
the other code is Java not D
It still
It seems std.database.sql not std.database. You can't build, for
example, a mongodb driver over this.
On Thursday, 28 May 2015 at 02:04:31 UTC, Erik Smith wrote:
I'm working on a standards grade interface implementation for
database clients in D. It defines a common interface
On Thursday, 28 May 2015 at 02:04:31 UTC, Erik Smith wrote:
https://github.com/cruisercoder/ddb
Maybe make the database providers interfaces instead of
data+dispatch? You're allocating the stuff anyway.
On Thursday, 28 May 2015 at 05:12:34 UTC, Vadim Lopatin wrote:
On Thursday, 28 May 2015 at 05:00:30 UTC, Rikki Cattermole
wrote:
On 28/05/2015 4:57 p.m., Robert burner Schadek wrote:
On Thursday, 28 May 2015 at 04:45:52 UTC, Erik Smith wrote:
Shouldn't the statement be reusable?
Yes it
On Thursday, 28 May 2015 at 04:57:55 UTC, Robert burner Schadek
wrote:
On Thursday, 28 May 2015 at 04:45:52 UTC, Erik Smith wrote:
Shouldn't the statement be reusable?
Yes it should. I added this use case:
auto stmt = con.statement(insert into table values(?,?));
stmt.execute(a,1);
On Thursday, 28 May 2015 at 09:18:53 UTC, Sebastiaan Koppe wrote:
That might be, but doing struct-table mappings will open a big
can of worms, not to mention all the syntax opinions (optional
and default values, table relationships, etc). Beter build
layer by layer.
In fact, Robert did
It seems std.database.sql not std.database. You can't build,
for example, a mongodb driver over this.
Maybe, but mongodb is a proprietary nosql interface rather than a
standard one so I'm not sure that it should be in std.
erik
Maybe make the database providers interfaces instead of
data+dispatch? You're allocating the stuff anyway.
Do you mean inheriting from interfaces like this?
class MysqlStatement : Statement {...}
I need deterministic resource management and I don't think
classes provide that. Using structs
code is Java not D
Then you open up table names, property serialization ext. ext.
Please no.
That is an ORM's job. I'm saying this from experience.
+1 for decoupling ORMish stuff from the DB driver layer but I
agree with Robert, std.database should have an ORM layer on top
of its DB drivers
On 28/05/2015 2:04 p.m., Erik Smith wrote:
I'm working on a standards grade interface implementation for database
clients in D. It defines a common interface (the implicit kind) and
allows for both native and polymorphic drivers. A key feature is a
range interface to query results.
Here's
On 28/05/2015 4:57 p.m., Robert burner Schadek wrote:
On Thursday, 28 May 2015 at 04:45:52 UTC, Erik Smith wrote:
Shouldn't the statement be reusable?
Yes it should. I added this use case:
auto stmt = con.statement(insert into table values(?,?));
stmt.execute(a,1);
stmt.execute(b,2);
I believe you're a aiming to low.
If you have a struct you could use traits and ctfe to generate
perfect sql statements. This would make it possible to a range of
struct Customers.
That would be awesome
Table a, b, c;
con.insert!Table(a);
...
if you use CTFE to create the statement string there is no
reason to reuse it.
it will be string literal, that's even better! Think Big. Think
D
the other code is Java not D
The statement reuse with binding is primarily for performance and
is
On Thursday, 28 May 2015 at 05:00:30 UTC, Rikki Cattermole wrote:
On 28/05/2015 4:57 p.m., Robert burner Schadek wrote:
On Thursday, 28 May 2015 at 04:45:52 UTC, Erik Smith wrote:
Shouldn't the statement be reusable?
Yes it should. I added this use case:
auto stmt = con.statement(insert
On Thursday, 28 May 2015 at 02:04:31 UTC, Erik Smith wrote:
Shouldn't the statement be reusable? I.e. bind variables and run
multiple times. From the code examples creating a statement and
binding variables seemed to be coupled.
Since one obvious use case would be running the behind a http
I'm working on a standards grade interface implementation for
database clients in D. It defines a common interface (the
implicit kind) and allows for both native and polymorphic
drivers. A key feature is a range interface to query results.
Here's the project page with the design highlights
On Thursday, 28 May 2015 at 03:40:36 UTC, Robert burner Schadek
wrote:
I believe you're a aiming to low.
If you have a struct you could use traits and ctfe to generate
perfect sql statements. This would make it possible to a range
of struct Customers.
That would be awesome
I agree that it
On Thursday, 28 May 2015 at 04:45:52 UTC, Erik Smith wrote:
Shouldn't the statement be reusable?
Yes it should. I added this use case:
auto stmt = con.statement(insert into table values(?,?));
stmt.execute(a,1);
stmt.execute(b,2);
stmt.execute(c,3);
struct Table;
Table a, b, c;
Shouldn't the statement be reusable?
Yes it should. I added this use case:
auto stmt = con.statement(insert into table values(?,?));
stmt.execute(a,1);
stmt.execute(b,2);
stmt.execute(c,3);
Since one obvious use case would be running the behind a http
server - vibe.d - using fibers and
What's the state of the module to interface with (relational)
databases?
On Sun, 01 Jul 2012 11:06:50 +0200, Tobias Pankrath tob...@pankrath.net
wrote:
What's the state of the module to interface with (relational) databases?
Not that I know of. Several people have created some interfaces, but they
are not compatible.
Steve Teale began some work, but nobody
Steve Teale began some work
his api design and a first implementation for mysql is available on his
site:
http://britseyeview.com/software/mysqld/
On Sun, 01 Jul 2012 14:55:58 +0200, Mirko Pilger pil...@cymotec.de wrote:
Steve Teale began some work
his api design and a first implementation for mysql is available on his
site:
http://britseyeview.com/software/mysqld/
I'm also in the process of cleaning it up (remove all pointer
I would like to have a look at it. Does anyone know if it's somewhere on
Github ?
Thanks.
Le 03/12/2011 01:02, Hans Uhlig a écrit :
One thing I notice is everyone seems to only be Targeting Relational
Databases. Any plans to support Flat, Object, Key Value, Hierarchical,
or Network Model systems? It would be nice to have at least
specification support for systems like
, and similar systems.
That is the reason why I originally suggested std.database is perhaps a
wrong place to cover all use-cases.
Second, there will be native (pure D) interfaces to various data sources,
and also there will be bindings to C libraries with the same purpose.
Third, handling of relational
for systems like membase(memcache), hbase,
vertica, csv files, and similar systems.
That is the reason why I originally suggested std.database is perhaps a
wrong place to cover all use-cases.
Second, there will be native (pure D) interfaces to various data sources,
and also there will be bindings
the project.
2. If we want to go the route of one std.database API with drivers for
each DBMS and consider ODBC one of several DBMSs, then we need to
define our own driver architecture, write a few drivers ourselves
(including probably ODBC), and hope that people will add more drivers.
That's a larger
to
ODBC as D's standard database interface, would complete the project.
2. If we want to go the route of one std.database API with drivers
for
each DBMS and consider ODBC one of several DBMSs, then we need to
define our own driver architecture, write a few drivers ourselves
(including
On Fri, 25 Nov 2011 12:53:36 -0500, Kagamin wrote:
Steve Teale Wrote:
So one question is where should such implementations go?
github?
Well, probably yes, but that sounds a bit like if you build it they will
come, which doesn't always work.
Another questions relates to the definition
Steve Teale Wrote:
It can be done using concepts: a template which instantiates to a set of
static asserts about what you want.
Is that what we do with Ranges?
Range concepts are boolean. There was a discussion on how to get detailed
diagnostic if concept is not met, so that one would
, and those that will apply to a broader view of
what comprises a database. In other words we should have std.sql and
std.database. (I use std purely for illustration.)
It's possibly worth mentioning that Microsoft had similar intentions
years ago when they introduced OLE DB - a generalized interface
Steve Teale Wrote:
So one question is where should such implementations go?
github?
Another questions relates to the definition of interfaces at module
level. We have interfaces that go hand-in-hand with classes built in
to the language. But if I wanted to say that two sql interface modules
Just a quick progress report.
Since it was clear that my original ideas for a MySQL D interface were
not going to make it into Phobos at least because of license issues, I
have been investigating the use of the published MySQL client/server
protocol (this was expressly removed from GPL, if it
If it comes down to it, someone can volunteer to help debug the code by
comparing it to the GPL'd library in areas where the spec seems to be
incorrect and completing the spec. I can help with this if you really
need it, I'd love to see native D support for MySQL, as it's my DB of
choice ;)
Steve Teale wrote:
It looks as if it is not a big deal to use the MySQL protocol rather than
the client library. I can now log in that way, so the rest should follow,
and I am working on the changeover. The current MySQL protocol has been
around since version 4.1.
Good to hear that! One note
Good to hear that! One note though. MySQL protocol has two row encoding
modes, text or binary. Please consider using the latter for better
performance.
Certainly - it would be pretty inefficient given the implementation
intended to use text.
Steve
Steve Teale Wrote:
Given that Piotr has, I think, already done the same work at protocol
level for Postgres, that SQLite is public domain, and that a similar API
can be done with ODBC, we should be able to cover a fair range of systems
without falling foul of GPL.
It is said ODBC is
Steve Teale wrote:
It looks as if it is not a big deal to use the MySQL protocol rather
than the client library. I can now log in that way, so the rest should
follow, and I am working on the changeover. The current MySQL protocol
has been around since version 4.1.
Unfortunately I am now
Steve Teale wrote:
Steve Teale wrote:
It looks as if it is not a big deal to use the MySQL protocol rather
than the client library. I can now log in that way, so the rest should
follow, and I am working on the changeover. The current MySQL protocol
has been around since version 4.1.
On Thu, 20 Oct 2011 13:41:05 -0400, Piotr Szturmaj bncr...@jadamspam.pl
wrote:
Steve Teale wrote:
Steve Teale wrote:
It looks as if it is not a big deal to use the MySQL protocol rather
than the client library. I can now log in that way, so the rest should
follow, and I am working on the
Please be cautious about reading GPL'd source code to understand the
protocol. It's possible to be in violation of the license based on
this.
It generally takes two people to do this correctly, one to read and
understand the original code, and one to implement the new version based
on
Kagamin Wrote:
Steve Teale Wrote:
Given that Piotr has, I think, already done the same work at protocol
level for Postgres, that SQLite is public domain, and that a similar API
can be done with ODBC, we should be able to cover a fair range of systems
without falling foul of GPL.
Steven Schveighoffer Wrote:
Please be cautious about reading GPL'd source code to understand the
protocol. It's possible to be in violation of the license based on this.
As long as he doesn't copy the code, there's no violation. He can even organize
code better (or worse), e.g. use OOP,
On Thu, 20 Oct 2011 15:56:24 -0400, Kagamin s...@here.lot wrote:
Steven Schveighoffer Wrote:
Please be cautious about reading GPL'd source code to understand the
protocol. It's possible to be in violation of the license based on
this.
As long as he doesn't copy the code, there's no
On 19.10.2011 01:52, foobar wrote:
Don Wrote:
On 17.10.2011 01:43, foobar wrote:
foobar Wrote:
Don Wrote:
You're assuming that the compiler can run the code it's generating. This
isn't true in general. Suppose you're on x86, compiling for ARM. You
can't run the ARM code from the compiler.
It looks as if it is not a big deal to use the MySQL protocol rather than
the client library. I can now log in that way, so the rest should follow,
and I am working on the changeover. The current MySQL protocol has been
around since version 4.1.
Given that Piotr has, I think, already done the
On 17.10.2011 01:43, foobar wrote:
foobar Wrote:
Don Wrote:
You're assuming that the compiler can run the code it's generating. This
isn't true in general. Suppose you're on x86, compiling for ARM. You
can't run the ARM code from the compiler.
This is quite possible in Nemerle's model of
Don Wrote:
On 17.10.2011 01:43, foobar wrote:
foobar Wrote:
Don Wrote:
You're assuming that the compiler can run the code it's generating.
This
isn't true in general. Suppose you're on x86, compiling for ARM. You
can't run the ARM code from the compiler.
This is quite
1 - 100 of 281 matches
Mail list logo
