quickfix-developers Mailing List for QuickFIX (Page 304)
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers — QuickFIX developers forum
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(5) |
Mar
(16) |
Apr
(15) |
May
(17) |
Jun
(33) |
Jul
(35) |
Aug
(34) |
Sep
(19) |
Oct
(40) |
Nov
(51) |
Dec
(43) |
| 2003 |
Jan
(45) |
Feb
(79) |
Mar
(124) |
Apr
(121) |
May
(132) |
Jun
(77) |
Jul
(110) |
Aug
(57) |
Sep
(48) |
Oct
(83) |
Nov
(60) |
Dec
(40) |
| 2004 |
Jan
(67) |
Feb
(72) |
Mar
(74) |
Apr
(87) |
May
(70) |
Jun
(96) |
Jul
(75) |
Aug
(147) |
Sep
(128) |
Oct
(83) |
Nov
(67) |
Dec
(42) |
| 2005 |
Jan
(110) |
Feb
(84) |
Mar
(68) |
Apr
(55) |
May
(51) |
Jun
(192) |
Jul
(111) |
Aug
(100) |
Sep
(79) |
Oct
(127) |
Nov
(73) |
Dec
(112) |
| 2006 |
Jan
(95) |
Feb
(120) |
Mar
(138) |
Apr
(127) |
May
(124) |
Jun
(97) |
Jul
(103) |
Aug
(88) |
Sep
(138) |
Oct
(91) |
Nov
(112) |
Dec
(57) |
| 2007 |
Jan
(55) |
Feb
(35) |
Mar
(56) |
Apr
(16) |
May
(20) |
Jun
(77) |
Jul
(43) |
Aug
(47) |
Sep
(29) |
Oct
(54) |
Nov
(39) |
Dec
(40) |
| 2008 |
Jan
(69) |
Feb
(79) |
Mar
(122) |
Apr
(106) |
May
(114) |
Jun
(76) |
Jul
(83) |
Aug
(71) |
Sep
(53) |
Oct
(75) |
Nov
(54) |
Dec
(43) |
| 2009 |
Jan
(32) |
Feb
(31) |
Mar
(64) |
Apr
(48) |
May
(38) |
Jun
(43) |
Jul
(35) |
Aug
(15) |
Sep
(52) |
Oct
(62) |
Nov
(62) |
Dec
(21) |
| 2010 |
Jan
(44) |
Feb
(10) |
Mar
(47) |
Apr
(22) |
May
(5) |
Jun
(54) |
Jul
(19) |
Aug
(54) |
Sep
(16) |
Oct
(15) |
Nov
(7) |
Dec
(8) |
| 2011 |
Jan
(18) |
Feb
(9) |
Mar
(5) |
Apr
(5) |
May
(41) |
Jun
(40) |
Jul
(29) |
Aug
(17) |
Sep
(12) |
Oct
(23) |
Nov
(22) |
Dec
(11) |
| 2012 |
Jan
(8) |
Feb
(24) |
Mar
(5) |
Apr
(5) |
May
(6) |
Jun
(5) |
Jul
(5) |
Aug
(5) |
Sep
(2) |
Oct
(9) |
Nov
(2) |
Dec
(18) |
| 2013 |
Jan
(25) |
Feb
(16) |
Mar
(8) |
Apr
(2) |
May
(16) |
Jun
(17) |
Jul
(2) |
Aug
(13) |
Sep
(3) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
(22) |
Apr
(9) |
May
(3) |
Jun
(1) |
Jul
(5) |
Aug
(11) |
Sep
(18) |
Oct
(4) |
Nov
(4) |
Dec
(3) |
| 2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
(4) |
Jun
(37) |
Jul
|
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
(4) |
Dec
(2) |
| 2016 |
Jan
(9) |
Feb
(3) |
Mar
(7) |
Apr
(1) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(3) |
Nov
(16) |
Dec
|
| 2017 |
Jan
(1) |
Feb
(15) |
Mar
(2) |
Apr
(12) |
May
(4) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(23) |
Dec
(8) |
| 2018 |
Jan
(2) |
Feb
(4) |
Mar
(2) |
Apr
(8) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(5) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(12) |
Aug
(5) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Diamond, C. <cli...@cs...> - 2002-07-12 16:08:42
|
That fixed the error - thanks Cliff -----Original Message----- From: OM...@th... [mailto:OM...@th...] Sent: 12 July 2002 16:17 To: cli...@cs... Cc: 'qui...@li...'; qui...@li... Subject: Re: [Quickfix-developers] Problems compiling QuickFIX with STLPort It looks like the reason is that STLPort does a forward declaration of std::string in the exceptions header, instead of including <string>. So what you probably need to do is do a #include <string> in the quickfix Exceptions.h header file. You can read more about this here, http://lists.boost.org/MailArchives/boost/msg18130.php. --oren |---------+-----------------------------------------------> | | "Diamond, Cliff" | | | <cli...@cs...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 07/12/2002 04:29 AM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: "'qui...@li...'" | | <qui...@li...> | | cc: | | Subject: [Quickfix-developers] Problems compiling QuickFIX with STLPort | >----------------------------------------------------------------------------------------------| Oren, I'm using stlport 4.5.3 (the current release version). I've commented out the default user option _STLP_NO_NEW_IOSTREAMS at the end of stl_user_config.h otherwise it attempts to use the Microsoft streams library and gets very confused about which headers to use. There's only one error (occurs three times) and one warning (occurs 646 times): 1. Error C2664 at Exceptions.h (line 65) (included by Parser.cpp, SocketConnection.cpp and ThreadedSocketConnection.cpp. The full error text is: C:\Source\quickfix\src\C++\Exceptions.h(65) : error C2664: '__thiscall _STL::logic_error::_STL::logic_error(const class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > &)' : cannot convert parameter 1 from 'char [ 16]' to 'const class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > &' Reason: cannot convert from 'char [16]' to 'const class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> >' Source or target has incomplete type 2. C4290 Warning (C++ Exception Specification ignored) wherever 'throw' syntax is included in a static function definition. Eg. C:\Source\quickfix\src\C++\FieldConvertors.h(97) : warning C4290: C++ Exception Specification ignored C:\Source\quickfix\src\C++\FieldConvertors.h(110) : warning C4290: C++ Exception Specification ignored C:\Source\quickfix\src\C++\FieldConvertors.h(124) : warning C4290: C++ Exception Specification ignored C:\Source\quickfix\src\C++\FieldConvertors.h(177) : warning C4290: C++ Exception Specification ignored C:\Source\quickfix\src\C++\FieldConvertors.h(206) : warning C4290: C++ Exception Specification ignored Regards Cliff This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. |
|
From: Diamond, C. <cli...@cs...> - 2002-07-12 16:07:06
|
No - I'm using Visual Studio 6 (CL 12).
Cliff
-----Original Message-----
From: JDD...@th... [mailto:JDD...@th...]
Sent: 12 July 2002 15:58
To: qui...@li...
Subject: Re: [Quickfix-developers] Problems compiling QuickFIX with
STLPort
I'm not yet sure about the STLport thing, but I'm curious about the
warnings. Are you using CL 13.00 (VS.NET)?
John Duncan
Collaborative Development Group
Thoughtworks, Inc
+1 (312) 953 6286
"Diamond, Cliff"
<cli...@cs...> To: "'qui...@li...'"
Sent by: <qui...@li...>
qui...@li...ur cc:
ceforge.net Subject: [Quickfix-developers] Problems compiling QuickFIX with STLPort
07/12/2002 04:29 AM
Oren,
I'm using stlport 4.5.3 (the current release version). I've commented out
the default user option _STLP_NO_NEW_IOSTREAMS at the end of
stl_user_config.h otherwise it attempts to use the Microsoft streams
library and gets very confused about which headers to use.
There's only one error (occurs three times) and one warning (occurs 646
times):
1. Error C2664 at Exceptions.h (line 65) (included by Parser.cpp,
SocketConnection.cpp and ThreadedSocketConnection.cpp. The full error text
is:
C:\Source\quickfix\src\C++\Exceptions.h(65) : error C2664: '__thiscall
_STL::logic_error::_STL::logic_error(const class
_STL::basic_string<char,class _STL::char_traits<char>,class
_STL::allocator<char> > &)' : cannot convert parameter 1 from 'char [
16]' to 'const class _STL::basic_string<char,class
_STL::char_traits<char>,class _STL::allocator<char> > &'
Reason: cannot convert from 'char [16]' to 'const class
_STL::basic_string<char,class _STL::char_traits<char>,class
_STL::allocator<char> >'
Source or target has incomplete type
2. C4290 Warning (C++ Exception Specification ignored) wherever 'throw'
syntax is included in a static function definition. Eg.
C:\Source\quickfix\src\C++\FieldConvertors.h(97) : warning C4290: C++
Exception Specification ignored
C:\Source\quickfix\src\C++\FieldConvertors.h(110) : warning C4290: C++
Exception Specification ignored
C:\Source\quickfix\src\C++\FieldConvertors.h(124) : warning C4290: C++
Exception Specification ignored
C:\Source\quickfix\src\C++\FieldConvertors.h(177) : warning C4290: C++
Exception Specification ignored
C:\Source\quickfix\src\C++\FieldConvertors.h(206) : warning C4290: C++
Exception Specification ignored
Regards
Cliff
This message is for the named person's use only. It may contain sensitive
and private proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you are not the intended recipient, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE
FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT
SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications
through its networks. Any views expressed in this message are those of the
individual sender, except where the message states otherwise and the sender
is authorized to state them to be the views of any such entity.
Unless otherwise stated, any pricing information given in this message is
indicative only, is subject to change and does not constitute an offer to
deal at any price quoted. Any reference to the terms of executed
transactions should be treated as preliminary only and subject to our
formal written confirmation.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Gadgets, caffeine, t-shirts, fun stuff.
http://thinkgeek.com/sf
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Gadgets, caffeine, t-shirts, fun stuff.
http://thinkgeek.com/sf
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity.
Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation.
|
|
From: <OM...@th...> - 2002-07-12 15:17:20
|
It looks like the reason is that STLPort does a forward declaration of std::string in the exceptions header, instead of including <string>. So what you probably need to do is do a #include <string> in the quickfix Exceptions.h header file. You can read more about this here, http://lists.boost.org/MailArchives/boost/msg18130.php. --oren |---------+-----------------------------------------------> | | "Diamond, Cliff" | | | <cli...@cs...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 07/12/2002 04:29 AM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: "'qui...@li...'" | | <qui...@li...> | | cc: | | Subject: [Quickfix-developers] Problems compiling QuickFIX with STLPort | >----------------------------------------------------------------------------------------------| Oren, I'm using stlport 4.5.3 (the current release version). I've commented out the default user option _STLP_NO_NEW_IOSTREAMS at the end of stl_user_config.h otherwise it attempts to use the Microsoft streams library and gets very confused about which headers to use. There's only one error (occurs three times) and one warning (occurs 646 times): 1. Error C2664 at Exceptions.h (line 65) (included by Parser.cpp, SocketConnection.cpp and ThreadedSocketConnection.cpp. The full error text is: C:\Source\quickfix\src\C++\Exceptions.h(65) : error C2664: '__thiscall _STL::logic_error::_STL::logic_error(const class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > &)' : cannot convert parameter 1 from 'char [ 16]' to 'const class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > &' Reason: cannot convert from 'char [16]' to 'const class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> >' Source or target has incomplete type 2. C4290 Warning (C++ Exception Specification ignored) wherever 'throw' syntax is included in a static function definition. Eg. C:\Source\quickfix\src\C++\FieldConvertors.h(97) : warning C4290: C++ Exception Specification ignored C:\Source\quickfix\src\C++\FieldConvertors.h(110) : warning C4290: C++ Exception Specification ignored C:\Source\quickfix\src\C++\FieldConvertors.h(124) : warning C4290: C++ Exception Specification ignored C:\Source\quickfix\src\C++\FieldConvertors.h(177) : warning C4290: C++ Exception Specification ignored C:\Source\quickfix\src\C++\FieldConvertors.h(206) : warning C4290: C++ Exception Specification ignored Regards Cliff This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: <JDD...@th...> - 2002-07-12 14:58:22
|
I'm not yet sure about the STLport thing, but I'm curious about the
warnings. Are you using CL 13.00 (VS.NET)?
John Duncan
Collaborative Development Group
Thoughtworks, Inc
+1 (312) 953 6286
"Diamond, Cliff"
<cli...@cs...> To: "'qui...@li...'"
Sent by: <qui...@li...>
qui...@li...ur cc:
ceforge.net Subject: [Quickfix-developers] Problems compiling QuickFIX with STLPort
07/12/2002 04:29 AM
Oren,
I'm using stlport 4.5.3 (the current release version). I've commented out
the default user option _STLP_NO_NEW_IOSTREAMS at the end of
stl_user_config.h otherwise it attempts to use the Microsoft streams
library and gets very confused about which headers to use.
There's only one error (occurs three times) and one warning (occurs 646
times):
1. Error C2664 at Exceptions.h (line 65) (included by Parser.cpp,
SocketConnection.cpp and ThreadedSocketConnection.cpp. The full error text
is:
C:\Source\quickfix\src\C++\Exceptions.h(65) : error C2664: '__thiscall
_STL::logic_error::_STL::logic_error(const class
_STL::basic_string<char,class _STL::char_traits<char>,class
_STL::allocator<char> > &)' : cannot convert parameter 1 from 'char [
16]' to 'const class _STL::basic_string<char,class
_STL::char_traits<char>,class _STL::allocator<char> > &'
Reason: cannot convert from 'char [16]' to 'const class
_STL::basic_string<char,class _STL::char_traits<char>,class
_STL::allocator<char> >'
Source or target has incomplete type
2. C4290 Warning (C++ Exception Specification ignored) wherever 'throw'
syntax is included in a static function definition. Eg.
C:\Source\quickfix\src\C++\FieldConvertors.h(97) : warning C4290: C++
Exception Specification ignored
C:\Source\quickfix\src\C++\FieldConvertors.h(110) : warning C4290: C++
Exception Specification ignored
C:\Source\quickfix\src\C++\FieldConvertors.h(124) : warning C4290: C++
Exception Specification ignored
C:\Source\quickfix\src\C++\FieldConvertors.h(177) : warning C4290: C++
Exception Specification ignored
C:\Source\quickfix\src\C++\FieldConvertors.h(206) : warning C4290: C++
Exception Specification ignored
Regards
Cliff
This message is for the named person's use only. It may contain sensitive
and private proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you are not the intended recipient, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE
FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT
SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications
through its networks. Any views expressed in this message are those of the
individual sender, except where the message states otherwise and the sender
is authorized to state them to be the views of any such entity.
Unless otherwise stated, any pricing information given in this message is
indicative only, is subject to change and does not constitute an offer to
deal at any price quoted. Any reference to the terms of executed
transactions should be treated as preliminary only and subject to our
formal written confirmation.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Gadgets, caffeine, t-shirts, fun stuff.
http://thinkgeek.com/sf
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
|
|
From: Alex H. <al...@an...> - 2002-07-12 10:03:06
|
On Thu, 2002-07-11 at 18:27, OM...@th... wrote: > > Alex, > > Correction. We do in fact have this example working correctly even with > the new scenarios added. So it seems that we can go ahead and start moving > the project over to shared libraries as you suggest. So I guess we can > then concentrate on figuring out why you are having problems with the JNI > wrapper on linux. Do you have any more insight into this? Could you also > post your autotools project for the JNI library you are building? > > --oren > Hi Oren, Good news on the shared libs - I look forward to the next release. I've enclosed a working JNI and C++ exceptions example based on the earlier exception example. It assumes you have JAVA_HOME set correctly and that you have javac and javah in your path. To build it do: ./configure make Then to test it: make check The configury is a bit of a hack at the moment as I'm using an old Automake. The newer 1.6.x releases have better java support. Cheers, Alex. |
|
From: Diamond, C. <cli...@cs...> - 2002-07-12 09:35:09
|
Oren,
I'm using stlport 4.5.3 (the current release version). I've commented out the default user option _STLP_NO_NEW_IOSTREAMS at the end of stl_user_config.h otherwise it attempts to use the Microsoft streams library and gets very confused about which headers to use.
There's only one error (occurs three times) and one warning (occurs 646 times):
1. Error C2664 at Exceptions.h (line 65) (included by Parser.cpp, SocketConnection.cpp and ThreadedSocketConnection.cpp. The full error text is:
C:\Source\quickfix\src\C++\Exceptions.h(65) : error C2664: '__thiscall _STL::logic_error::_STL::logic_error(const class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > &)' : cannot convert parameter 1 from 'char [
16]' to 'const class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > &'
Reason: cannot convert from 'char [16]' to 'const class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> >'
Source or target has incomplete type
2. C4290 Warning (C++ Exception Specification ignored) wherever 'throw' syntax is included in a static function definition. Eg.
C:\Source\quickfix\src\C++\FieldConvertors.h(97) : warning C4290: C++ Exception Specification ignored
C:\Source\quickfix\src\C++\FieldConvertors.h(110) : warning C4290: C++ Exception Specification ignored
C:\Source\quickfix\src\C++\FieldConvertors.h(124) : warning C4290: C++ Exception Specification ignored
C:\Source\quickfix\src\C++\FieldConvertors.h(177) : warning C4290: C++ Exception Specification ignored
C:\Source\quickfix\src\C++\FieldConvertors.h(206) : warning C4290: C++ Exception Specification ignored
Regards
Cliff
This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity.
Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation.
|
|
From: <OM...@th...> - 2002-07-11 17:27:31
|
Alex, Correction. We do in fact have this example working correctly even with the new scenarios added. So it seems that we can go ahead and start moving the project over to shared libraries as you suggest. So I guess we can then concentrate on figuring out why you are having problems with the JNI wrapper on linux. Do you have any more insight into this? Could you also post your autotools project for the JNI library you are building? --oren |---------+-----------------------------------------------> | | Alex Hornby <al...@an...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 07/11/2002 11:23 AM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: OM...@th... | | cc: quickfix-developers <qui...@li...> | | Subject: Re: [Quickfix-developers] compile problems with tradeclientgui | >----------------------------------------------------------------------------------------------| On Thu, 2002-07-11 at 14:16, OM...@th... wrote: > > Alex, > > Yes, we did get it and were able to get those examples to work properly, > thank you very much. However we added some new scenarios to that project > that we could not get working. John and I were actually discussing this a > couple days ago. I'd like to send you that project and perhaps you can > give some insight on why it isn't working. One of us will post our new > example sometime today. > > --oren > Okay, if you send it I'll have a look at. Cheers, Alex. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases & more http://thinkgeek.com/sf _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Alex H. <al...@an...> - 2002-07-11 16:23:07
|
On Thu, 2002-07-11 at 14:16, OM...@th... wrote: > > Alex, > > Yes, we did get it and were able to get those examples to work properly, > thank you very much. However we added some new scenarios to that project > that we could not get working. John and I were actually discussing this a > couple days ago. I'd like to send you that project and perhaps you can > give some insight on why it isn't working. One of us will post our new > example sometime today. > > --oren > Okay, if you send it I'll have a look at. Cheers, Alex. |
|
From: <OM...@th...> - 2002-07-11 15:59:32
|
Believe me, I absolutely see why it can be interpreted as such, but I do
not believe it is clear (which the FIX spec rarely is). In most places
that the FIX spec refers to session termination, they are refering to
termination of the sessions connection, not an actual reset of the session
itself. If you quote the full passage that you did in the previous message
you can see this more clearly.
"Normal termination of the message exchange session will be completed via
the exchange of Logout messages. Termination by other means should be
considered an abnormal condition and dealt with as an error. Session
termination without receiving a Logout should treat the counterparty as
logged out."
Here they are saying that if the session is terminated, it should be
treated as if the counter party logged out. Since there is no way to
detect if the counterparty has reset their session out of the blue, it
seems to me that session termination is synonymous with disconnection.
Also they say that a termination without a logout message should be treated
as if they had logged out. If logout behavior entailed resetting the
session, that would indicate a session would be reset during normal and
abnormal termination which I think we can both agree is not something we
would want. In any case I can not agree that the passage above is clear and
unambigous. There is also nothing that I can find in the protocol
specifications session state matrix to indicate that sequence numbers are
reset during logout.
And as you indicated the other engine you are using has a setting so they
have certainly run into others who have interpreted this passage
differently from them. The FIX committee is currently working on the FIX
4.3 errata. I would be happy to forward them this issue so they can
hopefully clarify their intention in the next document.
In any case, as the other engine has wisely observed, if a configuration
setting is added the point becomes moot.
And since our code is open source, the point is even mooter (such a word?
why not.)
Best,
--oren
|---------+----------------------------------------------->
| | Gene Gorokhovsky |
| | <mus...@ya...> |
| | Sent by: |
| | qui...@li...ur|
| | ceforge.net |
| | |
| | |
| | 07/11/2002 09:02 AM |
| | |
|---------+----------------------------------------------->
>----------------------------------------------------------------------------------------------|
| |
| To: qui...@li... |
| cc: |
| Subject: Re: [Quickfix-developers] Apparent session logout logic problem |
>----------------------------------------------------------------------------------------------|
I beg to disagree about what is FIX compliant and to
your spec quote I have my spec counterquote (from 4.1
spec)
"Logout - Normal termination of the message exchange
session will be completed via the exchange of Logout
messages. Termination by other means should be
considered an abnormal condition and dealt with as an
error"
This to my view clearly indicates that session is to
be terminated when logout is received, and therefore
sequence can be reset not only on ResetSeqNumFlag.
I believe that although session can exist across
multiple TCP/IP (or other carrier protocol)
connections, it cannot span past a Logout message.
In the current QuickFIX interpretation Logout message
serves absolutely no purpose except for message resync
handshaking -- quote contrary to its name.
I am attaching other vendors CFG file -- they have two
settings to deal with logout: separately whether to
reset session and whether to reset sequence, and the
comments clearly indicate that in their opionion both
session and sequence are to be reset on logout to be
in spec compliance.
Gene Gorokhovsky
--- OM...@th... wrote:
>
> Gene,
>
> This is how FIX defines a session:
>
> "A FIX session is defined as a bi-directional stream
> of ordered messages
> between two parties within a continuous sequence
> number series. A single
> FIX session can exist across multiple physical
> connections. Parties can
> connect and disconnect multiple times while
> maintaining a single FIX
> session. Connecting parties must bi-laterally agree
> as to when sessions are
> to be started/stopped based upon individual system
> and time zone
> requirements. It is recommended that a new FIX
> session be established once
> within each 24 hour period. It is possible to
> maintain 24 hour connectivity
> and establish a new set of sequence numbers by
> sending a Logon message with
> the ResetSeqNumFlag set."
>
> But never fear. QuickFIX was designed to operate
> with engines like the one
> you describe. Simply add the following lines to your
> onLogout method
> callback:
>
> void onLogout( const FIX::SessionID& sessionID )
> {
> FIX::Session* pSession =
> FIX::Session::lookupSession(sessionID);
> if(pSession) pSession->reset();
> }
>
> Now keep in mind that onLogout also gets called on a
> hard disconnect,
> because of another line in the spec ("Session
> termination without receiving
> a Logout should treat the counterparty as logged
> out."). If the engine you
> are connecting with is truly resetting with every
> logon/logout pair and not
> with abnormal disconnects, then you may want to move
> the above code to the
> fromAdmin callback and call it whenever you see a
> Logout message pass
> through.
>
> Since I have seen another engine that behaves in
> this way (CME's ORAPI), it
> may be a good idea to add a configuration setting
> called
> ResetSessionOnLogout or something.
>
> --oren
>
>
>
>
|---------+----------------------------------------------->
> | | Gene Gorokhovsky
> |
> | | <mus...@ya...>
> |
> | | Sent by:
> |
> | |
> qui...@li...ur|
> | | ceforge.net
> |
> | |
> |
> | |
> |
> | | 07/11/2002 02:07 AM
> |
> | |
> |
>
|---------+----------------------------------------------->
>
>
>
----------------------------------------------------------------------------------------------|
> |
> |
> | To:
> qui...@li...
> |
> | cc:
> |
> | Subject: [Quickfix-developers] Apparent
> session logout logic problem |
>
>
>
----------------------------------------------------------------------------------------------|
>
>
>
>
> Please forgive me if I am wildly off the mark, but
> should not the session be completely reset,
> including
> the target session num and file store, upon
> receiving
> a logout message?
> I have been testing QuickFIX interoperability with
> another engine using the ordermatch sample, and
> their
> test client keeps getting rejected on sessions after
> the first one, because it resets the msgnum back to
> 1
> after sending a valid logout, and QuickFIX does not
> That another vendor, which I cannot disclose, keeps
> separate message counters for every login/logout
> pair.
> In my view their approach corresponds better to FIX
> specification, which clearly indicates that logout
> message terminates session, nd therefore sequence
> numbers ought to be restarted.
> If I am right and this is indeed a problem, the
> quick
> and dirty way to change the behavior would be to
> perform a Session::reset() instead of
> Session::disconnect() when a logout message is
> received.
>
> Gene Gorokhovsky
>
>
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com
>
>
>
-------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> PC Mods, Computing goodies, cases & more
> http://thinkgeek.com/sf
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>
>
__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com(See attached file: engine.properties)
|
|
From: Gene G. <mus...@ya...> - 2002-07-11 14:02:29
|
I beg to disagree about what is FIX compliant and to
your spec quote I have my spec counterquote (from 4.1
spec)
"Logout - Normal termination of the message exchange
session will be completed via the exchange of Logout
messages. Termination by other means should be
considered an abnormal condition and dealt with as an
error"
This to my view clearly indicates that session is to
be terminated when logout is received, and therefore
sequence can be reset not only on ResetSeqNumFlag.
I believe that although session can exist across
multiple TCP/IP (or other carrier protocol)
connections, it cannot span past a Logout message.
In the current QuickFIX interpretation Logout message
serves absolutely no purpose except for message resync
handshaking -- quote contrary to its name.
I am attaching other vendors CFG file -- they have two
settings to deal with logout: separately whether to
reset session and whether to reset sequence, and the
comments clearly indicate that in their opionion both
session and sequence are to be reset on logout to be
in spec compliance.
Gene Gorokhovsky
--- OM...@th... wrote:
>
> Gene,
>
> This is how FIX defines a session:
>
> "A FIX session is defined as a bi-directional stream
> of ordered messages
> between two parties within a continuous sequence
> number series. A single
> FIX session can exist across multiple physical
> connections. Parties can
> connect and disconnect multiple times while
> maintaining a single FIX
> session. Connecting parties must bi-laterally agree
> as to when sessions are
> to be started/stopped based upon individual system
> and time zone
> requirements. It is recommended that a new FIX
> session be established once
> within each 24 hour period. It is possible to
> maintain 24 hour connectivity
> and establish a new set of sequence numbers by
> sending a Logon message with
> the ResetSeqNumFlag set."
>
> But never fear. QuickFIX was designed to operate
> with engines like the one
> you describe. Simply add the following lines to your
> onLogout method
> callback:
>
> void onLogout( const FIX::SessionID& sessionID )
> {
> FIX::Session* pSession =
> FIX::Session::lookupSession(sessionID);
> if(pSession) pSession->reset();
> }
>
> Now keep in mind that onLogout also gets called on a
> hard disconnect,
> because of another line in the spec ("Session
> termination without receiving
> a Logout should treat the counterparty as logged
> out."). If the engine you
> are connecting with is truly resetting with every
> logon/logout pair and not
> with abnormal disconnects, then you may want to move
> the above code to the
> fromAdmin callback and call it whenever you see a
> Logout message pass
> through.
>
> Since I have seen another engine that behaves in
> this way (CME's ORAPI), it
> may be a good idea to add a configuration setting
> called
> ResetSessionOnLogout or something.
>
> --oren
>
>
>
>
|---------+----------------------------------------------->
> | | Gene Gorokhovsky
> |
> | | <mus...@ya...>
> |
> | | Sent by:
> |
> | |
> qui...@li...ur|
> | | ceforge.net
> |
> | |
> |
> | |
> |
> | | 07/11/2002 02:07 AM
> |
> | |
> |
>
|---------+----------------------------------------------->
>
>
>----------------------------------------------------------------------------------------------|
> |
> |
> | To:
> qui...@li...
> |
> | cc:
> |
> | Subject: [Quickfix-developers] Apparent
> session logout logic problem |
>
>
>----------------------------------------------------------------------------------------------|
>
>
>
>
> Please forgive me if I am wildly off the mark, but
> should not the session be completely reset,
> including
> the target session num and file store, upon
> receiving
> a logout message?
> I have been testing QuickFIX interoperability with
> another engine using the ordermatch sample, and
> their
> test client keeps getting rejected on sessions after
> the first one, because it resets the msgnum back to
> 1
> after sending a valid logout, and QuickFIX does not
> That another vendor, which I cannot disclose, keeps
> separate message counters for every login/logout
> pair.
> In my view their approach corresponds better to FIX
> specification, which clearly indicates that logout
> message terminates session, nd therefore sequence
> numbers ought to be restarted.
> If I am right and this is indeed a problem, the
> quick
> and dirty way to change the behavior would be to
> perform a Session::reset() instead of
> Session::disconnect() when a logout message is
> received.
>
> Gene Gorokhovsky
>
>
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com
>
>
>
-------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> PC Mods, Computing goodies, cases & more
> http://thinkgeek.com/sf
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>
>
__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com |
|
From: Diamond, C. <cli...@cs...> - 2002-07-11 13:44:46
|
Has anyone got QuickFix to compile against stlport? I can't get it to compile at all. It compiles ok with the Microsoft STL (level 3 warnings only). Regards Cliff Diamond This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. |
|
From: <OM...@th...> - 2002-07-11 13:16:36
|
Alex,
Yes, we did get it and were able to get those examples to work properly,
thank you very much. However we added some new scenarios to that project
that we could not get working. John and I were actually discussing this a
couple days ago. I'd like to send you that project and perhaps you can
give some insight on why it isn't working. One of us will post our new
example sometime today.
--oren
Alex Hornby
<al...@an... To: OM...@th...
> cc: quickfix-developers <qui...@li...>
Subject: Re: [Quickfix-developers] compile problems with tradeclientgui
07/11/2002 03:42
AM
On Tue, 2002-07-09 at 22:32, OM...@th... wrote:
>
> Well that's a tough call. The reason we don't currently support JAVA for
> linux is that gcc (at least in our experience) has some issues throwing
> exceptions from shared objects (the JNI layer must be in a shared object
> for JAVA to access it). We are currently trying to isolate the problem to
> determine if there is something we can do. The avenues we are currently
> exploring are 1) gettings exceptions to work correctly in shared objects,
> 2) representing the logic without exceptions, 3) using some piece in the
> middle to isolate the JNI layer from the exceptions. We will keep
everyone
> updated when we have found a solution. It would also be very helpful to
> get some assistance from anyone who has experience with exceptions in
> shared objects.
>
> --oren
>
Hi Oren,
I recently sent a demonstration project that shows exceptions working
with shared objects on linux. I assume you have seen this?
There is no particular problem with shared objects on linux - for a
truly massive example of their use see the ACE+TAO CORBA ORB at
http://www.cs.wustl.edu/~schmidt/TAO.html. We have been using this for
around three years - exceptions work fine.
With quickfix 1.1 I have been able to build shared libraries and link
the example C++ programs to then. They work fine.
If you need further assistance I may be able to help with another
exception demonstration program.
Even if you still have JNI problems, perhaps you could still enable
shared libs anyway - after all they are useful and working in C++
already.
Cheers,
Alex.
|
|
From: <OM...@th...> - 2002-07-11 13:08:06
|
Gene,
This is how FIX defines a session:
"A FIX session is defined as a bi-directional stream of ordered messages
between two parties within a continuous sequence number series. A single
FIX session can exist across multiple physical connections. Parties can
connect and disconnect multiple times while maintaining a single FIX
session. Connecting parties must bi-laterally agree as to when sessions are
to be started/stopped based upon individual system and time zone
requirements. It is recommended that a new FIX session be established once
within each 24 hour period. It is possible to maintain 24 hour connectivity
and establish a new set of sequence numbers by sending a Logon message with
the ResetSeqNumFlag set."
But never fear. QuickFIX was designed to operate with engines like the one
you describe. Simply add the following lines to your onLogout method
callback:
void onLogout( const FIX::SessionID& sessionID )
{
FIX::Session* pSession = FIX::Session::lookupSession(sessionID);
if(pSession) pSession->reset();
}
Now keep in mind that onLogout also gets called on a hard disconnect,
because of another line in the spec ("Session termination without receiving
a Logout should treat the counterparty as logged out."). If the engine you
are connecting with is truly resetting with every logon/logout pair and not
with abnormal disconnects, then you may want to move the above code to the
fromAdmin callback and call it whenever you see a Logout message pass
through.
Since I have seen another engine that behaves in this way (CME's ORAPI), it
may be a good idea to add a configuration setting called
ResetSessionOnLogout or something.
--oren
|---------+----------------------------------------------->
| | Gene Gorokhovsky |
| | <mus...@ya...> |
| | Sent by: |
| | qui...@li...ur|
| | ceforge.net |
| | |
| | |
| | 07/11/2002 02:07 AM |
| | |
|---------+----------------------------------------------->
>----------------------------------------------------------------------------------------------|
| |
| To: qui...@li... |
| cc: |
| Subject: [Quickfix-developers] Apparent session logout logic problem |
>----------------------------------------------------------------------------------------------|
Please forgive me if I am wildly off the mark, but
should not the session be completely reset, including
the target session num and file store, upon receiving
a logout message?
I have been testing QuickFIX interoperability with
another engine using the ordermatch sample, and their
test client keeps getting rejected on sessions after
the first one, because it resets the msgnum back to 1
after sending a valid logout, and QuickFIX does not
That another vendor, which I cannot disclose, keeps
separate message counters for every login/logout pair.
In my view their approach corresponds better to FIX
specification, which clearly indicates that logout
message terminates session, nd therefore sequence
numbers ought to be restarted.
If I am right and this is indeed a problem, the quick
and dirty way to change the behavior would be to
perform a Session::reset() instead of
Session::disconnect() when a logout message is
received.
Gene Gorokhovsky
__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
|
|
From: Alex H. <al...@an...> - 2002-07-11 08:42:08
|
On Tue, 2002-07-09 at 22:32, OM...@th... wrote: > > Well that's a tough call. The reason we don't currently support JAVA for > linux is that gcc (at least in our experience) has some issues throwing > exceptions from shared objects (the JNI layer must be in a shared object > for JAVA to access it). We are currently trying to isolate the problem to > determine if there is something we can do. The avenues we are currently > exploring are 1) gettings exceptions to work correctly in shared objects, > 2) representing the logic without exceptions, 3) using some piece in the > middle to isolate the JNI layer from the exceptions. We will keep everyone > updated when we have found a solution. It would also be very helpful to > get some assistance from anyone who has experience with exceptions in > shared objects. > > --oren > Hi Oren, I recently sent a demonstration project that shows exceptions working with shared objects on linux. I assume you have seen this? There is no particular problem with shared objects on linux - for a truly massive example of their use see the ACE+TAO CORBA ORB at http://www.cs.wustl.edu/~schmidt/TAO.html. We have been using this for around three years - exceptions work fine. With quickfix 1.1 I have been able to build shared libraries and link the example C++ programs to then. They work fine. If you need further assistance I may be able to help with another exception demonstration program. Even if you still have JNI problems, perhaps you could still enable shared libs anyway - after all they are useful and working in C++ already. Cheers, Alex. |
|
From: Gene G. <mus...@ya...> - 2002-07-11 07:07:44
|
Please forgive me if I am wildly off the mark, but should not the session be completely reset, including the target session num and file store, upon receiving a logout message? I have been testing QuickFIX interoperability with another engine using the ordermatch sample, and their test client keeps getting rejected on sessions after the first one, because it resets the msgnum back to 1 after sending a valid logout, and QuickFIX does not That another vendor, which I cannot disclose, keeps separate message counters for every login/logout pair. In my view their approach corresponds better to FIX specification, which clearly indicates that logout message terminates session, nd therefore sequence numbers ought to be restarted. If I am right and this is indeed a problem, the quick and dirty way to change the behavior would be to perform a Session::reset() instead of Session::disconnect() when a logout message is received. Gene Gorokhovsky __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: <OM...@th...> - 2002-07-09 21:32:24
|
Well that's a tough call. The reason we don't currently support JAVA for linux is that gcc (at least in our experience) has some issues throwing exceptions from shared objects (the JNI layer must be in a shared object for JAVA to access it). We are currently trying to isolate the problem to determine if there is something we can do. The avenues we are currently exploring are 1) gettings exceptions to work correctly in shared objects, 2) representing the logic without exceptions, 3) using some piece in the middle to isolate the JNI layer from the exceptions. We will keep everyone updated when we have found a solution. It would also be very helpful to get some assistance from anyone who has experience with exceptions in shared objects. --oren |---------+-----------------------------------------------> | | Krishna Dagli <kd...@in...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 07/09/2002 04:06 PM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: "qui...@li..." | | <qui...@li...> | | cc: | | Subject: Re: [Quickfix-developers] compile problems with tradeclientgui | >----------------------------------------------------------------------------------------------| My mistake. I was trying to configure tradeclientgui on Linux, while documentation says java support currently available for windows. When java/linux support will be available? Thanks =========== Krishna OM...@th... wrote: > > Have you compiled the quickfix JAVA API and the C JNI layer? SessionID is > compiled into quickfix.jar. This file should show up in your quickfix\lib > directory once you build it. > > --oren > > |---------+-----------------------------------------------> > | | Krishna Dagli <kd...@in...> | > | | Sent by: | > | | qui...@li...ur| > | | ceforge.net | > | | | > | | | > | | 07/09/2002 02:43 PM | > | | | > |---------+-----------------------------------------------> > > ----------------------------------------------------------------------------------------------| > | | > | To: qui...@li... | > | cc: | > | Subject: [Quickfix-developers] compile problems with tradeclientgui | > > ----------------------------------------------------------------------------------------------| > > Hi, > > I'm able to compile tradeclientgui application. It says name > resolution failed for SessionID etc. Is this Session.java > file missing? > ======= > Krishna. > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Stuff, things, and much much more. > http://thinkgeek.com/sf > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: <JDD...@th...> - 2002-07-09 21:30:15
|
We're not sure. Right now, expect that it won't be made available any time
soon. There have been some discussions about it, whether it's currently
possible, and what not. We at TW believe there is a problem with exceptions
on linux preventing us from going forward with a linux port of the Java
stuff. We have also heard that we may be wrong about this. This is where we
left off.
We anticipated that most clients using QuickFIX would have a Windows UI on
a Windows or Unix back end. So far, this has been the case, but a couple of
people on the list have asked about Linux Java support, and so I assume
that (1) Java is being used for the overall server architecture and
QuickFIX is being tied in because it is speedy, (2) Java GUIs are being
used, sometimes on Linux, or (3) people think it'd be neat for all the
functionality to work on all platforms. While I agree with (3) it's not the
primary concern. If you need (1) then we would love to have your assistance
to make it possible, and we should get our heads together about how to do
it. If it's (2), then it's less of a concern for the overall market but we
will help to make this happen.
John Duncan
Collaborative Development Group
Thoughtworks, Inc
+1 (312) 953 6286
Krishna Dagli <kd...@in...>
Sent by: To: "qui...@li..."
qui...@li...ur <qui...@li...>
ceforge.net cc:
Subject: Re: [Quickfix-developers] compile problems with tradeclientgui
07/09/2002 04:06 PM
My mistake. I was trying to configure tradeclientgui on
Linux, while documentation says java support currently
available for windows.
When java/linux support will be available?
Thanks
===========
Krishna
OM...@th... wrote:
>
> Have you compiled the quickfix JAVA API and the C JNI layer? SessionID
is
> compiled into quickfix.jar. This file should show up in your
quickfix\lib
> directory once you build it.
>
> --oren
>
> |---------+----------------------------------------------->
> | | Krishna Dagli <kd...@in...> |
> | | Sent by: |
> | | qui...@li...ur|
> | | ceforge.net |
> | | |
> | | |
> | | 07/09/2002 02:43 PM |
> | | |
> |---------+----------------------------------------------->
> >
----------------------------------------------------------------------------------------------|
> |
|
> | To: qui...@li...
|
> | cc:
|
> | Subject: [Quickfix-developers] compile problems with
tradeclientgui |
> >
----------------------------------------------------------------------------------------------|
>
> Hi,
>
> I'm able to compile tradeclientgui application. It says name
> resolution failed for SessionID etc. Is this Session.java
> file missing?
> =======
> Krishna.
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Stuff, things, and much much more.
> http://thinkgeek.com/sf
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Stuff, things, and much much more.
http://thinkgeek.com/sf
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
|
|
From: Krishna D. <kd...@in...> - 2002-07-09 21:06:37
|
My mistake. I was trying to configure tradeclientgui on Linux, while documentation says java support currently available for windows. When java/linux support will be available? Thanks =========== Krishna OM...@th... wrote: > > Have you compiled the quickfix JAVA API and the C JNI layer? SessionID is > compiled into quickfix.jar. This file should show up in your quickfix\lib > directory once you build it. > > --oren > > |---------+-----------------------------------------------> > | | Krishna Dagli <kd...@in...> | > | | Sent by: | > | | qui...@li...ur| > | | ceforge.net | > | | | > | | | > | | 07/09/2002 02:43 PM | > | | | > |---------+-----------------------------------------------> > >----------------------------------------------------------------------------------------------| > | | > | To: qui...@li... | > | cc: | > | Subject: [Quickfix-developers] compile problems with tradeclientgui | > >----------------------------------------------------------------------------------------------| > > Hi, > > I'm able to compile tradeclientgui application. It says name > resolution failed for SessionID etc. Is this Session.java > file missing? > ======= > Krishna. > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Stuff, things, and much much more. > http://thinkgeek.com/sf > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Krishna D. <kd...@in...> - 2002-07-09 19:44:06
|
Hi, I'm able to compile tradeclientgui application. It says name resolution failed for SessionID etc. Is this Session.java file missing? ======= Krishna. |
|
From: Victor G. <vic...@ho...> - 2002-07-09 03:54:22
|
Hi, I have recently starting using QuickFix, and am not able to find a way to access repeating groups through the Java API. Is this supported? Thanks, Victor _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx |
|
From: Krishna D. <kd...@in...> - 2002-07-08 13:14:19
|
Hi, I'm new to quick-fix. I have gone through two sample code. It will be really helpful if someone can post some more sample programs. I'm not able to understand Sequence number generation after ctrl+c of ordermatcher and tradeclient. Next time they start from what ever is there in the log files. ======== Krishna. |
|
From: Justin P. <jp...@fs...> - 2002-06-23 22:21:46
|
Can someone tell me how to set an ExDestination Variable: According to FIX documentation I need to send field 100(Exdestination) to 2. Can someone tell me how to do that? Message.setField(FIX::ExDestination(exDestination)); Thanks, Justin |
|
From: <OM...@th...> - 2002-06-20 15:03:47
|
Yeah, I believe it is. It was replaced by org_quickfix_FileMessageStore.cpp. It also isn't included in the windows project file so you don't need to add it to the linux one either. --oren |---------+-----------------------------------------------> | | Alex Hornby <al...@an...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 06/20/2002 05:21 AM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: quickfix-developers <qui...@li...> | | cc: | | Subject: [Quickfix-developers] Missing header (or out of date .cpp) in java src dir | >----------------------------------------------------------------------------------------------| Hi, The header FileMessageStore.h seems to be missing from quickfix/src/java. Without it I can't build FileMessageStore.cpp. Perhaps this .cpp is obsolete and should be removed? Regards, Alex. ------------------------------------------------------- Bringing you mounds of caffeinated joy >>> http://thinkgeek.com/sf <<< _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Alex H. <al...@an...> - 2002-06-20 10:20:40
|
Hi, The header FileMessageStore.h seems to be missing from quickfix/src/java. Without it I can't build FileMessageStore.cpp. Perhaps this .cpp is obsolete and should be removed? Regards, Alex. |
|
From: Alex H. <al...@an...> - 2002-06-20 08:51:17
|
Hi, Well, I didn't know what was wrong with your exception example, so I re-jigged it to how I'd normally do things. I've tested it on i686-pc-linux-gnu and sparc-sun-solaris2.8 (both with GCC & GNU binutils). The good news its that it works perfectly. If you want it to work with the Sun WorkShop Pro compilers you'll need to update it to use a libtool 1.5 development release. I've attached a source tarball. Cheers, Alex. |
98 messages has been excluded from this view by a project administrator.
