If you look at the Release History of SQLite, you're presented with a list of releases:
2017-06-17 (3.18.2)
2017-06-16 (3.18.1) <-- :o
2017-06-08 (3.19.3)
2017-05-25 (3.19.2)
...
Why the releases after 2017-06-16 (3.19.3) have a decreased sub version number of 18 instead of rationally sticking to the current subversion and incrementing the third number?! Does the new changes applied to the 3.18.2 are also present in the currently "latest" version?! Or, maybe I'm totally lost in a desert of ignorance?!! Please shed some lights on this :)
Version 3.18.1 is the same as version 3.18.0, but with a bug fixed.
This version was made for users who did not want to update to 3.19.x but still wanted the bugfix.
Related
I'm making a Turbo Pascal 7.0 program for my class, it has to be on Graphic Mode.
A message pops up
BGI Error: Graphics not initialized (use InitGraph).
I'm already using InitGraph and graph.tpu and I specified the route as "C:\TP7\BGI".
My S.O is Windows 7 and I'm using DosBox 0.74, I already tried to paste all the files from the folder BGI into BIN.
What should I do?
Since dos doesn't have system graphic drivers, the BGI functions as such for BP7.
So in short, use a BGI suitable for your videocard. The ones supplied with BP7 are very old, there are newer, VESA ones that you could try.
Afaik 3rd party BGI needs to be registered explicitly in code though.
At first I have had this "missing Graph.tpu"- ... and later the "Use Initgraph"-issue too.
After hours trying (and reading some not politeful comments in the internet) I finally got Turbo Pascal 7 succesfully running (in Windows 10, x64). In summary I want to share "some secrets":
install the "TP(WDB)-7.3.5-Setup.msi" (comes from clever people in Vietnam)
make sure, that there's the CORRECT PATH to the "BGI"-directory in your program-code. For example:
driver := Detect;
InitGraph (driver, modus, 'c:\TPWDB\BGI');
(By the way: This is ALL, what's there to do with "Initgraph".)
make sure, that in TP7 under "Options" --> "Directories" are the CORRECT PATHS both to "C:\TPWDB\UNITS" and Your actual working dir e.g. "C:\TPWDB\myPrograms"
THAT's IT.
Annotations: The "Graph.TPU" (usually) is already in "UNITS" (together with "Graph3.tpu" by the way).
Hazzling around old driver's isn't needed even... :)
Just the correct paths... :)
Hope, that can help ...
I have upgraded quantstrat package from 0.7.7(installed on Jan 7th 2013) to 0.7.8, however old code does not work properly. looks like we can not put any entry orders niether buy or sell, and only exit orders are executed. Here is the detail. Someone knows major changes in add.rule or applyStrategy function or same issue has been reported?
We set up trading rule by add.rule()
add.rule(f,'ruleSignal',arguments=list(sigcol="DoSell",sigval=TRUE,orderqty=(-1*tradeSize),osFUN='osSUS',ordertype='market',TxnFees="calcTxnFee",prefer='Open'),type='enter',label=gExitLabel)
add.rule(f,'ruleSignal',arguments=list(sigcol="DoBuy", sigval=TRUE,orderqty=tradeSize,osFUN='osBuy',ordertype='market',TxnFees="calcTxnFee",prefer='Price'),type='enter',label=gEnterLabel)
add.rule(f,'ruleSignal',arguments=list(sigcol="DoStop", sigval=TRUE,orderqty=-1*tradeSize,osFUN='osStop',ordertype='stoplimit',threshold='StopLevel',TxnFees="calcTxnFee"),type='risk',label='Stop')
The problem we had is we don't get entry signal when we run applyStrategy ...... It seems that getOrderbook has "Buy" and "Sell" .....
applyStrategy(rs, rs) only applied sell signal ........(not buy)
[1] "2010-11-18 09:00:00 ABC -65660 # 4.6"
[1] "2010-12-07 09:00:00 ABC -37509 # 5.17"
However getOrderBook() recorded "Buy", and "Sell" in order .....
at the same time order.prices were set "0", order.status "replaced" and Prefer "Price" by the system
It is hard to understand what is your problem exactly: "no entry signal", "orderbook has Buy and Sell" (whatever that means), "order.prices were set to 0" ...
I see that you are using your own order sizing functions, could it have something to do with that? You may try dropping your order sizing functions for a test, just to check if your entry orders are being executed.
Otherwise I suggest that you provide a complete example so I can run it and check.
Please be aware that quantstrat is under heavy development and that the code is patched almost on a daily basis, although the version number may not always be bumped up. So make sure that you always download the latest code.
HTH,
Jan Humme.
I'm upgrading from rails 3 to 3.1.8 (and onwards). A couple of my tests are failing, one of which seemed at first glance to be because of the change from mysql2 gem (0.2.x to 0.3.x). However, it gets a little stranger. Here's what's happening.
In my test I am updating attributes on a model, and checking that they've saved:
...
post :create, :advertisement => #advertisement_attributes
assert_equal assigns(:blah).start_date, #blah_attributes[:start_date]
It is failing saying that they are different times.
If I put a binding.pry and jump in just before the assert_equal this is what I get:
a = assigns(:blah).start_date
b = #blah_attributes[:start_date]
a == b #false
a.to_s #"2012-10-17 20:46:12 UTC"
b.to_s #"2012-10-17 20:46:12 UTC"
a.to_i #1350506772
b.to_i #1350506772
a.to_i - b.to_i #0
So far.. I'm still confused as to why the == is returning false. But what is really odd is if I subtract the dates -
a - b #-0.989403009414673
If anyone can explain what's going on here I'd love to know!
Also, this same test was passing fine in rails 3 (no timezone was set for the application), any pointers to what has changed would also be handy!
I am looking for a working distribution of SQLite for OpenVMS. I tried building SQLite 3.7.9 from the amalgamation file, using patches I found in a mailing list, but it does not quite work.
I am using HP C V7.1-015 on OpenVMS Alpha 7.3-2.
Since I cannot install python, which seems to include SQLite3, I have to build from sources.
I compile using the following commands:
$ CC /OPTIMIZE -
/DEFINE=(SQLITE_THREADSAFE=0, -
SQLITE_OMIT_LOAD_EXTENSION=1, -
SQLITE_OMIT_COMPILEOPTION_DIAGS=1, -
SQLITE_OMIT_MEMORYDB=1, -
SQLITE_OMIT_TEMPDB=1, -
SQLITE_OMIT_DEPRECATED=1, -
SQLITE_OMIT_SHARED_CACHE=1, -
_USE_STD_STAT=ENABLE) -
/FLOAT=IEEE_FLOAT -
sqlite3.c
$ CC /OPTIMIZE -
/DEFINE=(SQLITE_THREADSAFE=0, -
SQLITE_OMIT_LOAD_EXTENSION=1, -
SQLITE_OMIT_COMPILEOPTION_DIAGS=1, -
SQLITE_OMIT_MEMORYDB=1, -
SQLITE_OMIT_TEMPDB=1, -
SQLITE_OMIT_DEPRECATED=1, -
SQLITE_OMIT_SHARED_CACHE=1, -
_USE_STD_STAT=ENABLE) -
/FLOAT=IEEE_FLOAT -
shell.c
I copied the defines from the mailing list, and added /FLOAT=IEEE_FLOAT to get rid of most warnings regarding floating points (related to overflows due to exponent 308).
During compilation I got some informationals and warnings.
I get the following messages while linking:
$ LINK shell.obj,sqlite3.obj
...
%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM, __STD_FSTAT
%LINK-I-UDFSYM, __STD_STAT
...
Since I am a little bit lost here, I rather have SQLite3 sources which compile on OpenVMS.
The specific problem you're getting from the linker arises from the fact that you've requested capability at compile time that your system doesn't have. I believe the _USE_STD_STAT option first became available in OpenVMS v8.2, yet you're on 7.3-2. Your compiler and your headers know what to do when _USE_STD_STAT is defined, but the functions to process the X/Open-compliant stat structure do not exist in the C run-time (CRTL in VMS parlance) on your system, and your linker is telling you, "ain't got those functions."
Ideally you would be able to upgrade your operating system. Current as of this writing is v8.4. v7.3-2 was released eight and a half years ago and v8.2 over seven years ago. I understand that there are technical, budgetary, and even political reason that upgrades aren't always possible. If it were me, and I were stuck on OpenVMS Alpha v7.3-2, I would try removing the _USE_STD_STAT=ENABLE from the compilation and see what blows up.
One of the side effects of enabling _USE_STD_STAT is that you also get _LARGEFILE along with it. If that's the only reason SQLite needs the option, you may be fine but limited to 4GB databases. I suspect there's more to it than that, i.e., SQLite very likely makes use of elements in the stat structure that do actually require the newer structure.
You can read up on the differences in the traditional and standards-compliant stat structures at http://h71000.www7.hp.com/doc/84final/5763/5763profile_062.html#index_x_1699.
I've recently improved my VMSish patch for SQLite and made it available for SQLite version 3.7.14.1: http://www.mail-archive.com/sqlite-users#sqlite.org/msg73570.html (or http://sqlite.1065341.n5.nabble.com/Building-SQLite-3-7-14-1-for-OpenVMS-td65277.html).
POSIX locking still doesn't work though, and I was unable to find out why.
Well, there was a message on the sqlite-users mailing list on getting SQLite 3.7.9 working on OpenVMS. I don't know how relevant that is to the version you've got (or if the patch was adopted by the SQLite developers; they're a bit picky for legal reasons IIRC) but it looks likely to be useful. Good luck.
Is there any way to create a cron expression for not running the job at all?
I though of using this expression :
0 0 0 1 1 ? 3099
...which will practically do the job as it will run on year 3099, but is there a cleaner way to do it?
If you're still looking for something robust even in the far future, try https://stackoverflow.com/a/13938099/1601531, where I suggest the use of February 31st in crontab entries which are never intended to execute.
0 0 5 31 2 ?
I needed a valid cron schedule (? syntax not working in my system) which resolves real dates, but to be effectively "never". My current best solution was to pick the most recent leap year and see what day Feb 29th fell on. Feb 29 2016 was a Monday, so the next Monday Feb 29 is currently furthest away.
0 0 29 2 1 yields the next 5 triggers as:
02/29/2044 00:00:00Z
02/29/2072 00:00:00Z
02/29/2112 00:00:00Z
02/29/2140 00:00:00Z
02/29/2168 00:00:00Z
Not perfect but it'll do.
Pick a date in the past.
That'll never happen again. Unless it's groundhog day. Just don't pick groundhog day.
I created a duplicate (click here to see) for your question, and agree with your initial proposal. After testing, it appears Quartz will never execute a cron expression with a year above 2300.
Opening your crontab file and deleting the entry would be the adequate way. Or you might as well simlink the executable that's called by the cronjob to an empty shell script.
Tell us more about your setup, then we'll see ...
Comment it out — put # sign in front of it. Very useful, especially if you're afraid you'll forget about your changes by the year 3099.
Another possibility is to make it execute dummy command, like true rm -rf /.