Stepping down as the module owner of editor/
As some of you may know, nobody has been actively working on the editor module for about 3 years now. I started working on this module about 6 years ago and as the newest and only person working on it, I started to own the Core::Editor module. I've tried to make occasional fixes and review patches in my spare time for the past 3 years, but currently with my other responsibilities I've been unable to even keep up with the occasional patch reviews. I think it's time for me to step down as the owner of editor/. This makes me sad, and I've tried various ways of finding an active contributor for this area of the code but have not had any success. If someone is interested to take this over, please let me know and I will do my best to help you. I am planning to finish my outstanding code reviews by the end of this month. -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Data migration from ftp.mozilla.org to S3, 1pm Pacific Tuesday 20th October
Nick Thomas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 21/10/15 9:22 am, EE wrote: What is S3? Does that mean that the newer versions will be at some other address, and if so, where? I mean Amazon S3, see http://aws.amazon.com/s3/ for more details. Really we're just changing the backend storage to a cloud system. You can continue to use https://ftp.mozilla.org to reach the usual places, although we encourage people to move to https://archive.mozilla.org. Same data, with a new name that doesn't default to the ftp protocol in Firefox. There will be some gaps in the data for a few days, notably in firefox/nightly firefox/tinderbox-builds firefox/try-builds These will disappear as data is synced up to S3. Cheers Nick Thomas -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWJ1vyAAoJENO8WgCvFBJMBPEH+wRUlo98atkH2Th2qVhpR653 Ua1F4CRYRtoCJWvbpDxgN/uKIxiL6xFA48YuaKpQaY+x8Usg19P5INY8LN+EAyNK x8/rdyVdDqW3jPQqfIKkqWfB7RGOzjRr7/vUik7cH2MWjE9Aw2AcHGdkgPCo4nJw /H9CsjG2BQ6DmtjP9VtsymSU9bCWlrtLJa6qbNBIyFOTGytvYqrKqC0B6IcJZXq2 96G+GjYSoM5j7fKCsHQeBqai3SehagaUuGUWId5+Bs/fSKTF7xLZZoYzHkf14oCt 6Pl9zeZaOZ1Xdzmuqad16yPqxQPAq4O8y7cJCKakf6y+dC4/bQvwRIdsH5/4dM4= =U8gQ -END PGP SIGNATURE- HTTPS does not default to FTP protocol even when the prefix is "ftp.", so https:\\ftp.mozilla.org will use secure HTTP. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Data migration from ftp.mozilla.org to S3, 1pm Pacific Tuesday 20th October
On 10/21/2015 2:33 AM, Nick Thomas wrote: although we encourage people to move to https://archive.mozilla.org. The column header sorting (e.g. ?C=M;O=D) has been broken for a couple weeks, and I see that both firefox and thunderbird don't even show dates in the listings any more: http://archive.mozilla.org/pub/firefox/releases/ SeaMonkey still has the nicer output, but with the broken sorting: http://archive.mozilla.org/pub/mozilla.org/seamonkey/releases/?C=M;O=D Will this be fixed, or is it going to continue to be a worse experience than it ever was with FTP? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendations: Canvas 2D Context & W3C DOM4
On 10/20/15 6:13 PM, L. David Baron wrote: W3C DOM4 http://www.w3.org/TR/dom/ deadline: November 3, 2015 Both specifications are derived from upstream WHATWG specifications. As of which date? I ask because this looks like a fairly old fork, containing various requirements that are known to not be web-compatible and which have long since been fixed upstream (e.g. the createAttribute mess). If there are comments you think Mozilla should send as part of the review, or if you think Mozilla should voice support or opposition to the specification, please say so in this thread. (I'd note, however, that there have been many previous opportunities to make comments, so it's somewhat bad form to bring up fundamental issues for the first time at this stage.) There are fundamental issues we've brought up before, and which continue to be unaddressed (though noted) in this specification. Or indeed upstream. I assume raising them at this point is not useful, of course. In general, I think we should make it clear that this specification as written is known to be not-web-compatible and that we have no plans to base implementation activity on this specification as a result. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendations: Canvas 2D Context & W3C DOM4
On 10/20/15 6:13 PM, L. David Baron wrote: Two W3C Proposed Recommendations are available for the membership of W3C (including Mozilla) to vote on, before they proceed to the final stage of being W3C Recomendation: Do you happen have links to the test suite results for these? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: moz_malloc, moz_realloc, moz_calloc and moz_free are no more
On Tuesday, March 31, 2015 at 9:00:01 AM UTC+3, Mike Hommey wrote: > Hi, > > In the next few weeks, there is going to be a reduction in the number of > our memory allocator wrappers/functions, for essentially the following > reasons: > - we have too many of them, > - developers rarely know which one to use, which results in: > - developers often make mistakes[1] > > This started today with the landing of bug 1138293, which effectively > removed moz_malloc, moz_realloc, moz_calloc and moz_free. > > They were replaced, respectively, with malloc, realloc, calloc and free, > because that works(tm). > > If you have pending patches that use moz_malloc, moz_realloc, > moz_calloc, moz_free, you can just remove the moz_ prefix. > > The infallible moz_xmalloc, moz_xrealloc and moz_xcalloc still do exist, > and memory allocated with them can be freed with free. > > With that being said, please refrain from using any of the functions > mentioned above. Please prefer the C++y new and delete. new is > infallible by default (equivalent to moz_xmalloc). If you need an > equivalent to moz_malloc, use fallible new instead: > > new (fallible) Foo() > > Please note that this shouldn't make uplifting harder. Platform patches > using malloc/free/new/delete should apply and work just fine on beta, > aurora and esr (with a few exceptions ; if you uplift something from > mfbt/mozglue that uses the memory allocator, please check with me). > > Cheers, > > Mike > > > 1. if you look for it, you'll find cases of one family used for >allocation and another for deallocation, for possibly close to all >combinations of families (NS_Alloc, nsMemory, moz_malloc, malloc, >new). Just pointing out that the removal of these methods might break proprietary code. Actually, it breaks "libqc_b2g_ril.so" >Failed to load native module at path >'/system/b2g/distribution/bundles/libqc_b2g_ril/libqc_b2g_ril.so': (80004005) >dlopen failed: cannot locate symbol "moz_free" referenced by >"libqc_b2g_ril.so"... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
[GFX] How to create an active stereoscopic openGL compositor window, and draw a WebGL framebuffer inside
Hi guys, I'm Geoffrey, VR UX product designer since 2005. My mozillian id is Hypergeff I'm currently digging into Mozilla GFX source code for the first time. I'd love to help Mozilla stepping into VR, and not only VR based on HMDs because VR will be much more than HMDs . So I'd like to create a proof of concept of webGL active stereoscopic rendering. (I'd like to achieve this kind immersive sketchfab viewer on a zSpace monitor, that I did with the Chromium Embedded Framwork: https://vimeo.com/85780695) There is only a few lines of code to achieve this, but I don't know where to implement it into Firefox code. The easiest way I think that should work, is to do a WebGL script which does left and right view rendering on top of each other, in a 1920*2400 canvas (each view sizing 1920*1200 ). >From this left/right framebuffer image, I will then draw the top part image in >the GL_Back_Left buffer and bottom part in the GL_BACK_RIGHT buffer. Before that, I have to declare stereo support to the openGL webGl layer window (pfd.dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER | PFD_STEREO; ) Here is the code I added in CEF that I know is working well for doing active stereoscopy 1. Set the openGL window to support stereo (PFD_STEREO) // Get the device context. hDC_ = GetDC(hWnd_); // Set the pixel format for the DC. ZeroMemory(&pfd, sizeof(pfd)); pfd.nSize = sizeof(pfd); pfd.nVersion = 1; pfd.dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER | PFD_STEREO; pfd.iPixelType = PFD_TYPE_RGBA; pfd.cColorBits = 24; pfd.cDepthBits = 16; pfd.iLayerType = PFD_MAIN_PLANE; format = ChoosePixelFormat(hDC_, &pfd); SetPixelFormat(hDC_, format, &pfd); 2. Do the left/right drawing from the top/bottom stereo rendered image void ClientOSRenderer::Render() { if (view_width_ == 0 || view_height_ == 0) return; ASSERT(initialized_); struct { float tu, tv; float x, y, z; } static vertices_imageTopPart[] = { // top half part of the image buffer {0.0f, 0.5f, -1.0f, -1.0f, 0.0f}, // bas gauche {1.0f, 0.5f, 1.0f, -1.0f, 0.0f}, // bas droite {1.0f, 0.0f, 1.0f, 1.0f, 0.0f}, // haut droite {0.0f, 0.0f, -1.0f, 1.0f, 0.0f} // haut gauche }; struct { float tu, tv; float x, y, z; } static vertices_imageBottomPart[] = { // bottom half part of the image buffer {0.0f, 1.0f, -1.0f, -1.0f, 0.0f}, // bas gauche {1.0f, 1.0f, 1.0f, -1.0f, 0.0f}, // bas droite {1.0f, 0.5f, 1.0f, 1.0f, 0.0f}, // haut droite {0.0f, 0.5f, -1.0f, 1.0f, 0.0f} // haut gauche }; glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); glMatrixMode(GL_MODELVIEW); glLoadIdentity(); // Match GL units to screen coordinates. glViewport(0, 0, view_width_, view_height_/2); glMatrixMode(GL_PROJECTION); glLoadIdentity(); glOrtho(0, 0, view_width_, view_height_/2, 0.1, 100.0); // clear drawing buffers and z-buffer(s) glFlush(); glDrawBuffer (GL_BACK); glClearColor(0.2f, 0.2f, 0.2f, 0.0f); // non-black bkgr, less ghosting glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); // Enable 2D textures. glEnable(GL_TEXTURE_2D); // Draw the facets with the texture. ASSERT(texture_id_ != 0); glBindTexture(GL_TEXTURE_2D, texture_id_); // offscreen texture given from chromium rendering // Draw the left eye view glFlush(); glDrawBuffer (GL_BACK_LEFT); // draws to left buffer glInterleavedArrays(GL_T2F_V3F, 0, vertices_imageBottomPart); glDrawArrays(GL_QUADS, 0, 4); // If we were doing a solid rendering, we would want to clear the //z-buffer before each eye's rendering, since some stereo //hardware/driver implementations only include one shared //z-buffer glClear (GL_DEPTH_BUFFER_BIT); // Draw the right eye view glFlush(); glDrawBuffer (GL_BACK_RIGHT); glInterleavedArrays(GL_T2F_V3F, 0, vertices_imageTopPart); glDrawArrays(GL_QUADS, 0, 4); // Disable 2D textures. glDisable(GL_TEXTURE_2D); glFlush(); } My issue: * In Firefox, I disabled angle and set openGL as the preferred Layer renderer from the about:config window. Then I added PFD_STEREO dwFlag in WGLLibrary::CreateDummyWindow(HDC *aWindowDC) from GLContextProviderWGL.cpp at line 58. (At this point I am still not sure if the final WebGL layer compositing window will be openGL or DirectX...) Now I'm looking for a place where I could do the WebGL stereo image cutting and back_left/back_right glDrawBuffer. I tried to do it in GLContext.h, in void fFlush() and in raw_fBlitFramebuffer(), but it always crashes at runtime when I add one of those 2 openGL commands: mSymbols.fInterleavedArrays or mSymbols.fDrawArrays Would you guys have some advice in the way to achieve this ? Thanks much Cordialement / Best Regards, Geoffrey SUBILEAU Lead VR UX and R&D manag
Re: Data migration from ftp.mozilla.org to S3, 1pm Pacific Tuesday 20th October
Nick Thomas wrote on 10/21/2015 11:46 AM: > * to reach older builds you can use > http://ftp-origin-scl3.mozilla.org/pub/mozilla.org/firefox/ > * please don't get comfortable with that, we'll just be using > archive.mozilla.org soon For how long will the ftp-origin-scl3.mozilla.org host be online? We had to temporarily switch mozdownload to make use of that host, to circumvent the gaps of builds and the changed HTML structure for parsing. It will take us some days to get it all fixed and I don't want to use archive.mozilla.org again as long as not all builds have been transfered over. Thanks -- Henrik ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendations: Canvas 2D Context & W3C DOM4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi David, On 10/21/2015 12:13 AM, L. David Baron wrote: > Two W3C Proposed Recommendations are available for the membership > of W3C (including Mozilla) to vote on, before they proceed to the > final stage of being W3C Recomendation: > > HTML Canvas 2D Context http://www.w3.org/TR/2dcontext/ deadline: > October 21, 2015 (tomorrow!) > > W3C DOM4 http://www.w3.org/TR/dom/ deadline: November 3, 2015 > > Both specifications are derived from upstream WHATWG > specifications. > > If there are comments you think Mozilla should send as part of the > review, or if you think Mozilla should voice support or opposition > to the specification, please say so in this thread. (I'd note, > however, that there have been many previous opportunities to make > comments, so it's somewhat bad form to bring up fundamental issues > for the first time at this stage.) > > (Sorry, should have sent these out a bit sooner.) Does this mean that the W3C is claiming that the features in these forks have interoperable implementations, and should we point out what utter nonsense such a claim would be? Thanks Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJWJ4O4AAoJEOXgvIL+s8n25y8IAJrdgXFgQOeabi8p9Lix2guQ DuUZT78TaPtRvF1cBbMpcWqzHgcUxYVGyntJWC+4UzJZ0uew8s5ONM3kIKO/VyNh KMKDRtTMxxRn00Y8LOPaLf3UW+Fcv+4Y1beifmlYougJYd0kagSqmNpJEnXcCz97 QUIgl1+8uRyoJwiNxPg0nQJB+oHQ0LPe9kZYFQHEwC1wyyWgDTUZORAJMaRtNXOr CstZ1wcMzmas098g3tSRJgX9bkee+PKXoVxm9t/nNDTlcCDTd+W157xAdFS4uqQW h8rLO7OFAF/wMJtNJ8uuA3W70BiBWOqG5cw2VfxQiKNqmZ0YRBJeQfgISuEkX+I= =iaAo -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Data migration from ftp.mozilla.org to S3, 1pm Pacific Tuesday 20th October
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 An update on how this went. We are now transitioned to S3 storage for firefox, mobile, and thunderbird. calendar will move over in the near future. There was a long tree closure, sorry for the length of that. The major issues still in play are: * data synchronization to S3 is ongoing, and should be complete in the next few days. There are gaps in firefox/nightly, firefox/tinderbox-builds, and firefox/try-builds * to reach older builds you can use http://ftp-origin-scl3.mozilla.org/pub/mozilla.org/firefox/ * please don't get comfortable with that, we'll just be using archive.mozilla.org soon * we apologize for any inconvience this may cause you, it was not the intention before the migration * try builds will fail to upload (and run tests!) unless you push your changes on top of recent tip of inbound, specifically https://hg.mozilla.org/integration/mozilla-inbound/rev/0ee21e8d5ca6 or later (bug 1216907) * the hazard builds aren't uploading their analysis files (bug 1216859) * spidermonkey builds and logs are invisible until bug 1216859 is comple te * if you open a raw log in treeherder it will download instead of shown in a new tab. This is part of a wider problem with the Content-Type header not being set (bug 1216804). On 21/10/15 1:37 am, Nick Thomas wrote: > Starting today at 1pm a subset of directories will be migrated > from the FTP server to S3 - firefox, mobile, thunderbird, and > calendar. The window for this work is two hours long, and the trees > will stay open (unless things go very badly). This is part of a > project lead by the Cloud Ops group, assisted by Release > Engineering . > > Things you should know * existing links to ftp.mozilla.org will > continue to work, although archive.mozilla.org is now considered > the canonical domain * while the data has been copied over, during > the cutover the most recent files may not available on the new > system. Synchronization will continue after the cutover to > backfill them * treeherder will continue to show the results of > jobs, but the logs may be affected by the previous point. > Treeherder is designed to retrieve the log again when necessary * > tests will continue to run because they use a separate storage > system (except for mozilla-beta, mozilla-release and mozilla-esr38) > * paths like firefox/tinderbox-builds/*/latest will stop being > updated, and later will be removed (they were originally added for > gaia-try, and that is now defunct) * in the near future directories > like firefox/releases/latest/ will be emptied. README files with > alternative options will be provided > > Please contact the sheriff, or #releng, if you want to bring any > issues to our attention. bug 1211732 is tracking bug. > > Nick Thomas (Release Engineering) > -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWJ171AAoJENO8WgCvFBJMlt0H/0iS7kJAIdOxqZwjAFnweMaA aXHVhtcB3GbPWiwd9Yfxy2Q/lV+zVF6mVUFpoRV5kHRGZzCp9IdcRaIyNJ8fVdmo y9hUZk9qcwEkRyd5SI/AH5gpzOL79e1ubq9Vv2DYtnrLvBBohK2M7zZ1lT4N6PJv sPzISzwlMj9Kz8CMQKfgngJPqzHbrzKTL/JsR9Oc2JKKgUjYA0RJYCX62+AIpzJp AuslJ9wruNQRkukyZdsZKWANO4A/XDKx8OsIzl/w7UoAWmcpqWy/ZnFaNs/1N6hW F5Xcj2ML9BDgm8D9xpDZoPWYbSsET2C/r6Engu1+gmVQWezCJqmjbjH5gj+TZJQ= =KdrQ -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Data migration from ftp.mozilla.org to S3, 1pm Pacific Tuesday 20th October
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 21/10/15 9:22 am, EE wrote: > What is S3? Does that mean that the newer versions will be at > some other address, and if so, where? I mean Amazon S3, see http://aws.amazon.com/s3/ for more details. Really we're just changing the backend storage to a cloud system. You can continue to use https://ftp.mozilla.org to reach the usual places, although we encourage people to move to https://archive.mozilla.org. Same data, with a new name that doesn't default to the ftp protocol in Firefox. There will be some gaps in the data for a few days, notably in firefox/nightly firefox/tinderbox-builds firefox/try-builds These will disappear as data is synced up to S3. Cheers Nick Thomas -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWJ1vyAAoJENO8WgCvFBJMBPEH+wRUlo98atkH2Th2qVhpR653 Ua1F4CRYRtoCJWvbpDxgN/uKIxiL6xFA48YuaKpQaY+x8Usg19P5INY8LN+EAyNK x8/rdyVdDqW3jPQqfIKkqWfB7RGOzjRr7/vUik7cH2MWjE9Aw2AcHGdkgPCo4nJw /H9CsjG2BQ6DmtjP9VtsymSU9bCWlrtLJa6qbNBIyFOTGytvYqrKqC0B6IcJZXq2 96G+GjYSoM5j7fKCsHQeBqai3SehagaUuGUWId5+Bs/fSKTF7xLZZoYzHkf14oCt 6Pl9zeZaOZ1Xdzmuqad16yPqxQPAq4O8y7cJCKakf6y+dC4/bQvwRIdsH5/4dM4= =U8gQ -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform