|
PureBytes Links
Trading Reference Links
|
>Throwing away stuff that is no longer productive or interesting.
Yes, you are right.
Good to have you there for the occasional 'sanity check'.
This editor is tempting me.
http://notepad-plus.sourceforge.net/uk/site.htm
I pretty certain that a kind Amisoul uploaded an AFL language pack that will customise syntax checking ... now that I am starting to nibble at other languages, and C++ plugins, it might have a higher enough justification score to get me to download a trial.
The negative would be dependence on others for language pack upgrades after AB, or NotePad upgrades, and loss of live visual debugging ... I don't think I would lose algorithm debugging because AB uses a third party debugger anyway (I think .. not sure how that works).
Looking at the superior features of NotePad++, and the open source status, one wonders why Tomasz doesn't bite the bullet and make it the default editor, or at least allow us to select is as a default i.e. why not piggyback on the efforts of scores of programmers working on NotePad++ instead of maintaining his own (perhaps maintain the AFL language pack) ... one of his policies is not to 'bloat' aB and he rides on the back of Windows for some of the core admin functions, like delete database, so why not make NotePad++ official. Of course he has other policies and priorities that we don't know about. Anyway enough dreaming ... back to working with what I've got.
--- In amibroker@xxxxxxxxxxxxxxx, i cs <ics4mer@xxx> wrote:
>
> Agreed.
>
> That's when you gotta give it an enema and revise naming standards etc.
>
> For me an opportunity to revise what you I'm doing and making sure
> I am staying on track. Throwing away stuff that is no longer
> productive or interesting.
>
> Z
>
>
>
>
>
>
> ________________________________
> From: brian_z111 <brian_z111@xxx>
> To: amibroker@xxxxxxxxxxxxxxx
> Sent: Thursday, 18 June, 2009 10:29:40 AM
> Subject: [amibroker] Re: A question of style
>
>
>
>
>
> > Searching the code is an issue - I'm sort of getting around it with naming
> > conventions.
>
> Yes, but that only takes you so far .... nuances in the code, as it develops, means my file names start with the same generic root but develop into variants ... identified by suffixes ... trying to differentiate the differences between the variants, via naming conventions, stretches the imagination.
>
> Now I have named variants and named versions of variants ... which one was it again that has that particular section of code in it?
>
> --- In amibroker@xxxxxxxxx ps.com, i cs <ics4mer@ > wrote:
> >
> > Hi Brian
> >
> > Thanks for your feedback.
> >
> > I think I'll go down the path I mentioned.
> >
> > InfoSelect is seems like a useful product- I'd never heard of it before. I
> > probably won't get it though. I'm pretty disciplined about source code
> > control and backups.
> >
> > Searching the code is an issue - I'm sort of getting around it with naming
> > conventions.
> >
> >
> >
> > Take care.
> >
> > RZ
> >
> >
> >
> >
> > ____________ _________ _________ __
> > From: brian_z111 <brian_z111@ ...>
> > To: amibroker@xxxxxxxxx ps.com
> > Sent: Thursday, 18 June, 2009 9:04:41 AM
> > Subject: [amibroker] Re: A question of style
> >
> >
> >
> >
> >
> > A lot of the heavy hitters collect and archive code from this forum etc and manage their snippets via third party software .... I assume they cut/copy and paste snippets as required e.g. Herman and others use Infoselect.
> >
> > --- In amibroker@xxxxxxxxx ps.com, "brian_z111" <brian_z111@ ...> wrote:
> > >
> > > So far I haven't had the need for long algorithms, or a lot of them, but I have found that maintaining AFL files lacks a few tools.
> > >
> > > Admittedly I am a messy worker and only saved by the fact that I don't archive other peoples code and don't archive all of my own forever.
> > >
> > > Up until now I have just relied on creating folder hierarchies and using the P_XYZ convention, etc, to delineate which files are primarily written as an indicator or scan etc.
> > >
> > > On top of that I have experimented with creating templates, with some all purpose code pre-written in them, but not as an #include.
> > >
> > > #includes seems like one of the 'logical' options .... the algorithmic traders seem to go down that path.
> > >
> > > I imagine that this also requires some ongoing management and possibly the need to remember what is in each #include template, as well as tracking versions, adding deleting new stuff as required .... I am generally opposed to continually adding tasks to my computer maintenance list.
> > >
> > > I am not sure if there are any execution implications that flow on from always loading up, at preprocessing, if you aren't going to use most of what is loaded (seems to be massive overkill).
> > >
> > >
> > >
> > > Three things seem to be lacking from my perspective:
> > >
> > > - finding the file you want from amongst a large number of files/folders ... AB needs the ability to search amongst the AFL files to find the file that has certain code in it
> > >
> > >
> > > - custom auto complete (like an excel macro that we assign to a key).
> > >
> > > One solution might be to use another editor, to get the benefit of search and customcomplete, but then any useful features in the AFLEditor will be lost and new maintenance issues created.
> > >
> > > For me the only two features of the AFLEditor I would miss are syntax checking and synchronisation between the current edit and the charts (I use apply indicator and watch the indicator to see how my code changes change the plot quite a bit ... if it wasn't for that basic need I would change editors).
> > >
> > >
> > > --- In amibroker@xxxxxxxxx ps.com, "ics4mer" <ics4mer@> wrote:
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > Just wondering how people out there are organising their
> > > > AFL code between plots, backtests, explorations etc.
> > > >
> > > > Lets say I have 5 indicators which each require 50 lines
> > > > of code to draw a plot, in other words too large to
> > > > maintain in separate AFL files.
> > > >
> > > > Lets say I also want them all in a single exploration.
> > > >
> > > > So logically it seems that I should place each indicator
> > > > into an include file and include that into each of the AFL
> > > > "types" so I'd have "include <myTA_Tool.h> " in my b_backtest,
> > > > e_exploration, and p_plot files?
> > > >
> > > > Just wondering how everybody else is handling this?
> > > >
> > > > RZ
> > > >
> > >
> >
> >
> >
> >
> >
> > Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
> > Show me how: http://au.mobile. yahoo.com/ mail
> >
>
>
>
>
>
> Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
> Show me how: http://au.mobile.yahoo.com/mail
>
------------------------------------
**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|