Feature Requests item #1067575, was opened at 2004-11-16 11:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=1067575...
Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: dynamic importing of externals and name spaces
Initial Comment: i would like to import internals dynamically inside a Pd patch.
; pd import externalname
; pd import directory/externalname
; pd import ../externalname
====================================== name spaces for externals would be nice, too
; pd import externalname
which gives you
externalname.object1 externalname.object2 externalname.object3
; pd importwithoutnamespace externalname
which gives you
object1 object2 object3
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=1067575...
SourceForge.net wrote:
Feature Requests item #1067575, was opened at 2004-11-16 11:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=1067575...
ahm.
so these are the weaknesses of feature-request-trackers: people start requesting things that are already there....
Initial Comment: i would like to import internals dynamically inside a Pd patch.
not sure what "internals" mean here.
mfg.as.dr IOhannes
On Tue, 16 Nov 2004, Johannes M Zmoelnig wrote:
ahm.
so these are the weaknesses of feature-request-trackers: people start requesting things that are already there....
I think thats not a weakness. Look at it from to positive point of view, it means that users like the new console.
Initial Comment: i would like to import internals dynamically inside a Pd patch.
not sure what "internals" mean here.
I think it means externals. Although I do not agree that namespaces are needed, if you want to do them right they need to have per patch scoping. The implementation of this might be a bit difficult though.
If you don't offer the possibility of having a concept like "using namespace xyz", then they are about the same as using per developers prefixes ala pdp_ z_ ix_ ...
Guenter
On Nov 16, 2004, at 2:12 PM, Johannes M Zmoelnig wrote:
SourceForge.net wrote:
Feature Requests item #1067575, was opened at 2004-11-16 11:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/? func=detail&atid=478073&aid=1067575&group_id=55736
ahm.
so these are the weaknesses of feature-request-trackers: people start requesting things that are already there....
This has nothing to do with the Feature Tracker at all, but will happen regardless of which method is used to request features. For example, already existing features are frequently requested on these lists. Does that mean the Pd lists are not useful?
.hc
Initial Comment: i would like to import internals dynamically inside a Pd patch.
not sure what "internals" mean here.
mfg.as.dr IOhannes
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
________________________________________________________________________ ____
"The arc of history bends towards justice." Dr. Martin Luther King, Jr.
Hans-Christoph Steiner wrote:
ahm.
so these are the weaknesses of feature-request-trackers: people start requesting things that are already there....
This has nothing to do with the Feature Tracker at all, but will happen regardless of which method is used to request features. For example, already existing features are frequently requested on these lists.
true
Does that mean the Pd lists are not useful?
no, of course not.
i did not try to be offensive or (too) sarcastic.
of course it is good to have requests for already existing features, as you can close them fairly fast and thus have good response-times (a bit of irony)
now to me the question arises, should feature requests be discussed on the mailing list ? if so, prior to posting a feature request? so you can get answers immediately; btw. do the requesters get feed-back when their request's status changes (i guess anonymous will get none) ? so they'll know that they can now do what thay always wanted to (or not, in case) does this sound arrogant ? i mean "dude, ask before requesting! and google before asking!" and of course the tracker is more anonymous and you don't have to be subscribed to any mailing-list.
or after the feature request ? i guess so, as that is the point of directing it to pd-dev.
i still think that the feature-requester is a good thing.
i just found it amazing that of the first 3 requests (that were sent to pd-dev), two where already implemented: i admit, one is brand new (not even released officially); but the other one is there since i know pd. and while being amazed i wrote my email. i don't know, how i should have expressed my amazement differently.
mfg.as.dr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote: now to me the question arises, should feature requests be discussed on the mailing list ? if so, prior to posting a feature request?
I think, discussing this on the list prior to "requesting" is not neccessary. Feature requests in turn can turn into discussions on the list. For example, my request for a settable route could be discussed here. However of course one should check, if a feature is already present, before requesting it. This can be done by asking on the list first. But finding out if a feature is present does not exactly require "discussion", as it's either there or not or in development.
i just found it amazing that of the first 3 requests (that were sent to pd-dev), two where already implemented:
Bad luck. :)
Ciao
-
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Johannes M Zmoelnig
-
SourceForge.net