[Ktechlab-devel] Cleaning up the simulator
Zoltan Padrah
zoltan.padrah at gmail.com
Sat Mar 27 21:06:52 UTC 2010
2010/3/26 Julian Bäume <julian at svg4all.de>
> > My question is how should be the Simulator class implemented? It's good
> > enough a singleton as it was? The problem becomes tricky when we consider
> > the plugin structure... Or should we use come class from ktechlatform?
> For now, I would like to change the code as little, as possible. So I'd
> prefer
> using a singleton, again.
>
Then the simulator class will have to be loaded at application launch, or
strange things will happen.
> Another thing I want to discuss is removing all GPSimProcessor calls and
> references from the simulator. I prepared a patch, that does this and
> without
> this, we won't have any PIC support in the simulator, but at least it
> compiles
> for me, now ;) (it doesn't link, because I haven't finished the other
> classes
> in that directory, yet.. ) Is it okay to temporarily remove PIC support and
> bring that feature back later?
>
I'd recommend to place the PIC support in a separate plugin. It also
introduces an external dependency (gpsim). For now just exclude building
that plugin.
>
> bye then
> julian
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Ktechlab-devel mailing list
> Ktechlab-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20100327/9f96fd8f/attachment.html>
More information about the Ktechlab-devel
mailing list