>I think it is too much effort for a few shaders. IMO, we should compile the >pbk files and keep the binaries around till there is a need to change them. >Pretty much what you have been doing for the past few days :-)
That pretty much my position, in more elegant and concise terms ;-) -----Message d'origine----- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 18 décembre 2013 18:35 À : dev@flex.apache.org Objet : Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2) On Dec 18, 2013 9:07 AM, "Alex Harui" <aha...@adobe.com> wrote: > > > > On 12/18/13 6:59 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> > wrote: > > >>"Another possibility is that we leave the PBK's where they are and > >>simply add new build targets to flex-sdk build script. That might > >>be simpler and gives us the option of reverting back to a single > >>package if we find that we can someday." > > > >> Yeah. So what are your thoughts now? > > > >- given that the PBK didn't change for years, and will probably never > >change, > >- given the "Jenkins running as a service" requirement, and that I > >don't see how it could be solved, apart from rewriting the compiler > >so that I does not need access to the gpu. > I had a meeting with the engineer who wrote most of the PB compiler. > He says that the PBK to PBJ pipeline shouldn't have dependencies on > the gnu, but other PBK to XXX pipelines do, so it should be possible > to modify the compiler and get rid of the window dependency. > > > > >I would think that we will never need/have to revert back to the > >single package. > > > >My impression is that we should consider this PBK/PBJ as a sort of " > >frozen legacy stuff", and handle them in a completely separate > >package, if that makes the build process simpler and clearer. > Well, I am making it a separate package. The question is whether you > think we should also move this code out of the flex-sdk repo. > > > >This is really just an impression, and some "common sense". > > > >> I've been trying to get a look at the pixel bender compiler source > >>to determine if it is worth donating to Apache Flex. > >> If we could get enough stuff to have control of the compiler would > >>we write a Linux version and then go back to a single package? > > > >That is a possibility, but it's a lot of work. > >So given the reasons above, is it worth the effort? > Another thing to consider: What if the PB compiler stops working on > Windows or Mac someday due to an OS incompatibility? When we don't > own the tools and the tools are not under active development, we run a risk. > Who knows when Adobe would respond. I think PB compiler was last > shipped in Creative Suite 5.5. > > We could also simply move away from PBK as folks eventually move away > from FP 10.x. > I've been told that Alchemy shaders will outperform PB shaders in the > more recent players. At least using the Installer, we can have separate install paths to use or not use PB shaders based on the FP/AIR versions the user selects. > > Also, I'm not sure how much work it really is. The compiler code base > is large, but the portion we need is not so large, and we might just > try to work from a grammar spec and byte code spec and get Falcon to do it. > > We need to think through whether we want to support PB "forever". I think it is too much effort for a few shaders. IMO, we should compile the pbk files and keep the binaries around till there is a need to change them. Pretty much what you have been doing for the past few days :-) Thanks, Om > > > > >Regards, > > > >Maurice > > > >-----Message d'origine----- > >De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 18 > >décembre 2013 15:37 À : dev@flex.apache.org Objet : Re: [DISCUSS] > >Discuss Release Apache Flex PixelBender Package 1.0 > >(RC2) > > > > > > > >On 12/17/13 11:45 PM, "Maurice Amsellem" > ><maurice.amsel...@systar.com> > >wrote: > > > >>>Well, re-read the end of that thread and let me know where you stand. > >> > >>Alex wrote: > >>"Another possibility is that we leave the PBK's where they are and > >>simply add new build targets to flex-sdk build script. That might > >>be simpler and gives us the option of reverting back to a single > >>package if we find that we can someday." > >> > >>is this the point you are talking about ? > >Yeah. So what are your thoughts now? I've been trying to get a look > >at the pixel bender compiler source to determine if it is worth > >donating to Apache Flex. If we could get enough stuff to have > >control of the compiler would we write a Linux version and then go > >back to a single package? > >> > >>Maurice > >> > >>-----Message d'origine----- > >>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 18 > >>décembre > >>2013 00:48 À : dev@flex.apache.org Objet : Re: [DISCUSS] Discuss > >>Release Apache Flex PixelBender Package 1.0 > >>(RC2) > >> > >> > >> > >>On 12/17/13 3:35 PM, "Maurice Amsellem" > >><maurice.amsel...@systar.com> > >>wrote: > >> > >>>> The goal was to not move the PBK files out to a different repo > >>>> and instead, package a subset of the flex-sdk repo. > >>> > >>>Why can't it be on a different repo ? > >>It can. > >>>From our early discussion on the subject (see email thread > >>>"PixelBender and Builds.a.o"), I understood that PBK sources were > >>>moved to a sub project in flex-utilities. > >>>Which means PBK sources and any reference to pixelbender should be > >>>completely removed from flex sdk. > >>>Morever, the pixel-bender project in flex-utilities was supposed to > >>>have its own build.xml. > >>>The result of the new pixel-bender build would be manually > >>>committed to dist svn repo (and voted for). > >>At the end of that discussion (around December 12), you talked me > >>out of putting it in a different repo. > >>> > >>>IMO, it would be much simpler to do it that way than "logically > >>>partitioning" the flex-sdk sources and build files. > >>Well, re-read the end of that thread and let me know where you stand. > >> > >>> > >>>WDYT ? > >>> > >>>Maurice > >>> > >>>-----Message d'origine----- > >>>De : Justin Mclean [mailto:jus...@classsoftware.com] Envoyé : > >>>mercredi > >>>18 décembre 2013 00:19 À : dev@flex.apache.org Objet : Re: > >>>[DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 > >>>(RC2) > >>> > >>>Hi, > >>> > >>>> OK. Good point about the overlay of the notice files. I'll add > >>>> an ant target to copy just the pbk/pbj. > >>>That would be required for the CI anyway wouldn't it? > >>> > >>>> The goal was to not move the PBK files out to a different repo > >>>> and instead, package a subset of the flex-sdk repo. > >>>Can we actually do that ie does it follow Apache release guidelines? > >>>I'm not sure. Does that mean we also need to vote on a release a > >>>version of pixel bender when making a new SDK release? > >>> > >>>> Do you think everything on this list is required? > >>>Not everything, It is expected that someone can take the source > >>>release and compile it and verify it to what's in version control. > >>> > >>>> 1) can we tell folks in the RELEASE_NOTES not to run > >>>> release-pixelbender target and say that it is for extracting this > >>>> package from a full flex-sdk repo? > >>>We can say what we want in RELEASE_NOTE/README. But it seem odd to > >>>me that you need the full Flex SDK is required just to make a > >>>release of pixel bender. What do other people think? > >>> > >>>> 2) can we say that the LICENSE file contains extra licenses that > >>>> may only apply to the full repo? > >>>I would assume that LICENSE/NOTICE file needs to refer to the > >>>actual release (and any upstream projects) they are in not any > >>>downstream projects. The Apache licence make reference to the > >>>NOTICE file so we would need to legally comply with that. > >>> > >>>> 3) can we say that the build.xml and properties files reference > >>>> the full flex-sdk build? > >>>Does this mean we need to make a new PB release every time they change? > >>> > >>>> 4) can we say that the clean target doesn't work? > >>>I think it would be expected that it should work. > >>> > >>>Thanks, > >>>Justin > >> > > >
