On Sun, 26 Feb 2012, Vinzent Höfler wrote:
On Sat, 25 Feb 2012 19:15:54 +0100, ik wrote:
I found the following amazing lecture that present a new idea of a
development tool, that I think will interest you all:
http://vimeo.com/36579366
Impressive, indeed. And I am usually not that easily
On Sun, 26 Feb 2012 11:43:38 +0100 (CET)
Michael Van Canneyt wrote:
>
>
> On Sun, 26 Feb 2012, Vinzent Höfler wrote:
>
> > On Sat, 25 Feb 2012 19:15:54 +0100, ik wrote:
> >
> >> I found the following amazing lecture that present a new idea of a
> >> development tool, that I think will interes
On Sunday 26 of February 2012 11:43:38 Michael Van Canneyt wrote:
> I don't see him doing this in huge corporate administrative business
> programs where hundreds of database tables are involved.
and that tables can contain billion of rows ... so visualisation won't be so
snappy :)
zeljko
_
On Sun, Feb 26, 2012 at 13:25, zeljko wrote:
> On Sunday 26 of February 2012 11:43:38 Michael Van Canneyt wrote:
>
>
>> I don't see him doing this in huge corporate administrative business
>
>> programs where hundreds of database tables are involved.
>
>
> and that tables can contain billion of ro
That was the seventh message on a subject which is not related to FPC in
any recognizable way. Although not a very frequent poster, I still need
to be on this list because I chose FPC for some of my professional work,
and I usually learn a lot from following some of the discussions on the
list. Why
Roland Schäfer schrieb:
I am just very busy and really
just beg you to respect my decision to be on the "fpc-pascal" list and
not "visions-other".
Then why don't you simply ignore (delete) the posts with the subject
"Amazing new development tools"?
That's what I am doing: Just open posts whic
On Sun, 26 Feb 2012, ik wrote:
On Sun, Feb 26, 2012 at 13:25, zeljko wrote:
On Sunday 26 of February 2012 11:43:38 Michael Van Canneyt wrote:
I don't see him doing this in huge corporate administrative business
programs where hundreds of database tables are involved.
and that tables
On 26 Feb 2012, at 13:24, Jürgen Hestermann wrote:
> Roland Schäfer schrieb:
>> I am just very busy and really
>> just beg you to respect my decision to be on the "fpc-pascal" list and
>> not "visions-other".
>>
> Then why don't you simply ignore (delete) the posts with the subject "Amazing
>
Hello,
I translated the following struct
struct iphdr {
#if defined(__LITTLE_ENDIAN_BITFIELD)
__u8ihl:4,
version:4;
#elif defined (__BIG_ENDIAN_BITFIELD)
__u8version:4,
ihl:4;
#else
#error "Please fix "
#endif
__u8tos;
_
Answering myself:
On Sun, Feb 26, 2012 at 14:54, ik wrote:
> Hello,
>
> I translated the following struct
>
> struct iphdr {
> #if defined(__LITTLE_ENDIAN_BITFIELD)
> __u8 ihl:4,
> version:4;
> #elif defined (__BIG_ENDIAN_BITFIELD)
> __u8 version:4,
>
On 26 Feb 2012, at 13:54, ik wrote:
> to the following Pascal record:
>
>
> iphdr= record
> {$IFDEF ENDIAN_LITTLE}
> jhl : Cardinal; // __u8 ihl:4,
> version : Cardinal; // version:4
The ":4" in C means "4 bits", not 4 bytes. The correct translation in th
On Sun, Feb 26, 2012 at 15:08, Jonas Maebe wrote:
>
> On 26 Feb 2012, at 13:54, ik wrote:
>
>> to the following Pascal record:
>>
>>
>> iphdr = record
>> {$IFDEF ENDIAN_LITTLE}
>> jhl : Cardinal; // __u8 ihl:4,
>> version : Cardinal; // version:4
>
> The ":4"
On 26 Feb 2012, at 14:16, ik wrote:
> I'ved replaced it to
>
> iphdr= bitpacked record
This is wrong. The record is a C record, and hence follows {$packrecord c}
rules. "bitpacked record" overrides any current {$packrecords x} setting. That
is the reason why I used the nested bitpacked re
On Sun, Feb 26, 2012 at 15:19, Jonas Maebe wrote:
>
> On 26 Feb 2012, at 14:16, ik wrote:
>
>> I'ved replaced it to
>>
>> iphdr = bitpacked record
>
> This is wrong. The record is a C record, and hence follows {$packrecord c}
> rules. "bitpacked record" overrides any current {$packrecords x} s
Hello all,
For desktop environments, there are mature projects on data persistance.
Press Objects, TiOPF... desktop developers can be proud of the tools
they have.
What about CGI environments? Is there something already developed? Yes,
we can use SQLDB. It's really a very good component. How
On Sun, 26 Feb 2012, Luciano de Souza wrote:
Hello all,
For desktop environments, there are mature projects on data persistance.
Press Objects, TiOPF... desktop developers can be proud of the tools they
have.
What about CGI environments? Is there something already developed? Yes, we
can
Actually, reading the tiOPF, I found the support for Firebird, Microsoft
SQL Server, Oracle, but not for PostgreSQL. This is the first reason. I
really don't know how proper tiOPF is when we focuses on CGI
development. At a first look, the project seemed to be very complex to
use, but of course
You can use rtti and create a base class that knows how to save/load
itself from sql database...
2012/2/26 Luciano de Souza :
> Actually, reading the tiOPF, I found the support for Firebird, Microsoft SQL
> Server, Oracle, but not for PostgreSQL. This is the first reason. I really
> don't know how
On 26.02.2012 19:28, Luciano de Souza wrote:
Actually, reading the tiOPF, I found the support for Firebird, Microsoft
SQL Server, Oracle, but not for PostgreSQL. This is the first reason. I
really don't know how proper tiOPF is when we focuses on CGI
development. At a first look, the project seem
On 26 February 2012 18:19, Luciano de Souza wrote:
>
> What about CGI environments?
Simply use tiOPF for that too. We do, and it works perfectly. We share
all our business objects and business rules between CGI and GUI
Desktop apps, plus all that code is unit tested in the same test suite
too.
On 26 February 2012 20:28, Luciano de Souza wrote:
> Actually, reading the tiOPF, I found the support for Firebird, Microsoft SQL
> Server, Oracle, but not for PostgreSQL.
tiOPF has a SqlDB (included with the Free Pascal Compiler) backend. As
it stands (in the public repository), SqlDB support in
21 matches
Mail list logo
