[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