- Pharo-users - lists.pharo.org

Re: [Pharo-users] [Vm-dev] [Pharo-dev] issue with large file path on windows

by Henrik Johansen

> On 24 Aug 2015, at 4:59 , Ben Coman <btc(a)openInWorld.com> wrote: > > > (CC'd vm-dev) > > On Mon, Aug 24, 2015 at 12:09 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> And If you want to review the changes: >> >> https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-lo… > > I don't have a Windows machine to test on, but I perused the changes. > one spelling defect ../platforms/win32/vm/sqWin32.h, line 452 "functiosn" > > Now my curiosity is aroused regarding sqFileDeleteNameSize() in [1]. > Where does its parameter "char* fileNameIndex" get its null termination? > I can only guess maybe the following definition in primitiveFileDelete.st [2] > <var: 'nameIndex' type: 'char *'> > automatically appends a null to the Smalltalk string. My understanding > is that the Smalltalk string's internal representation is not null > terminated. > > I ask since the sqFileDeleteNameSize()'s comment "convert the file > name into a null-terminated C string" indicates the null is added by > MultiByteToWideChar(), but [3] indicates that is not true -- that the > output of MultiByteToWideChar() is only null terminated if the input > is null terminated. That's not what 3 indicates, the way I read it: "cbMultiByte [in] Size, in bytes, of the string indicated by the lpMultiByteStr parameter. Alternatively, this parameter can be set to -1 if the string is null-terminated. " "cchWideChar [in] Size, in characters, of the buffer indicated by lpWideCharStr. If this value is 0, the function returns the required buffer size, in characters, including any terminating null character" So we first make a call using cbMultiByte > 0 and cchWideChar = 0, which then returns the size of null-terminated WCHAR-buffer needed to hold the conversion of non-null terminated (but sized) parameter. (sz = size) Then create that buffer, assign it to win32Path, and convert into it the CONVERT_MULTIBYTE_TO_WIDECHAR_PATH macro. The Win APIs are written in a way that they seldom (never?) allocate memory, instead you'll see this pattern of "call me once with size = NULL to get the required size, then allocate and call me again with the actual pointer/size" Cheers, Henry

Aug. 24, 2015

Re: [Pharo-users] [Pharo-dev] issue with large file path on windows

by Ben Coman

(CC'd vm-dev) On Mon, Aug 24, 2015 at 12:09 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > And If you want to review the changes: > > https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-lo… I don't have a Windows machine to test on, but I perused the changes. one spelling defect ../platforms/win32/vm/sqWin32.h, line 452 "functiosn" Now my curiosity is aroused regarding sqFileDeleteNameSize() in [1]. Where does its parameter "char* fileNameIndex" get its null termination? I can only guess maybe the following definition in primitiveFileDelete.st [2] <var: 'nameIndex' type: 'char *'> automatically appends a null to the Smalltalk string. My understanding is that the Smalltalk string's internal representation is not null terminated. I ask since the sqFileDeleteNameSize()'s comment "convert the file name into a null-terminated C string" indicates the null is added by MultiByteToWideChar(), but [3] indicates that is not true -- that the output of MultiByteToWideChar() is only null terminated if the input is null terminated. Also, anyone know if the concern "BIG WARNING about the return value and the `cbMultiByte` parameter" expressed near the end of [3] is relevant? [1] ../pharo-vm/platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c [2] ../pharo-vm/mc/VMMaker.oscog.package/FilePlugin.class/instance/primitiveFileDelete.st [3] https://msdn.microsoft.com/en-us/library/windows/desktop/dd319072(v=vs.85).…

Aug. 24, 2015

Re: [Pharo-users] issue with large file path on windows

by Nicolai Hess

2015-08-24 13:34 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 23 Aug 2015, at 6:09 , Nicolai Hess <nicolaihess(a)web.de> wrote: > > And If you want to review the changes: > > > https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-lo… > > > 2015-08-23 13:44 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > >> For those who had problems with pharo on windows and github based >> repositories, >> I built a windows vm with support for long paths: >> >> >> https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari… >> >> >> For browsing directories with large paths (FileList or Inspect), >> you may need one additional change in the image (But I am not really sure >> about that) : >> >> DiskStore>>initialize >> super initialize. >> maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ]. >> >> >> please test and give feedback. >> >> This wasn't as easy as I thought, and I had to make some more changes >> for the file permissions (the stat-functions don't work for files with >> long paths). >> Please test other file/folder operations. >> >> >> nicolai >> >> >> >> > > Thank you Henrik, for looking at this > + #define CONVERT_MULTIBYTE_TO_WIDECHAR_PATH(buffer, size, > fileNameString, fileNameLength) { \+ buffer = (WCHAR*)alloca((size+4+1)* > sizeof(WCHAR));\+ buffer[0] = L'\\';buffer[1] = L'\\'; buffer[2] = L'?'; > buffer[3] = L'\\';\+ MultiByteToWideChar(CP_UTF8, 0, fileNameString, > fileNameLength, buffer + 4, size);\+ buffer[size + 4] = 0;\+ size += 4;} > > > - Is an alloca version really worth it for the potential problems? > It is what Marcel used for the long path support in the squeak vm (I would have copy and paste the whole change, but I couldn't find the appropriate change for directory functions). > - Also, LONG_PATH_PREFIX_SIZE is defined above in the header, should > probably use this instead of 4 in the last two lines? > Yes > - The comment on lines 111/164/265/381, while not modified, are somewhat > incorrect, null-terminated C-string indicates UTF8, which we are converting > from, not into. > Right, I ll chang that > > I'm curious what the "\\?\" prefix does to hasCaseSensitiveDuplicate > (adding a new ? segment to the path), but I cba to understand that code, > and considering > int caseSensitiveFileMode = 0; > if(!caseSensitiveFileMode) return 0; > > I guess it doesn't really matter. > Yes, I tried to make this change in a way that does not break the case sensitive duplicate check, but even without my change, enabling the caseSenstiveFileMode makes the windows vm unusable. So, at least, it is no worse. > > Otherwise, looks good to me! > > Cheers, > Henry >

Aug. 24, 2015

Re: [Pharo-users] MSOffice DOCX generation?

by H. Hirzel

An initial version of a DOCX export (Headings and tables) here http://ss3.gemtalksystems.com/ss/Tabular.html (click on 'latest' and load configuration and Tabular*.mcz file). --Hannes On 8/9/15, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > And as Model 0 > > Model 0 Subset > ----------------------- > Headings > Tables (here comes your TABULAR model into action) > > This means it can be a TabularDOCXExport class in > http://ss3.gemtalksystems.com/ss/Tabular.html for a start. > > On 8/9/15, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> I consider an evolution of models with increasing complexity >> >> The goal is to have at least something as here but in certain areas more >> http://davidgohel.github.io/ReporteRs/word.html >> >> >> So it is >> >> Model 1 Subset >> ----------------------- >> >> Headings >> Paragraphs >> Tables (here comes your TABULAR model into action) >> Images >> pagebreak >> >> >> Model 2 Subset >> ----------------------- >> = Model 1 plus >> >> TOC >> sections >> Columns >> hrefs >> >> >> Model 3 Subset >> ----------------------- >> ??? >> not yet defined >> >> >> Formatting >> ---------------- >> >> Maybe direct formatting in the code >> >> but later surely all done with styles (no direct formatting) >> >> The styles have >> bold / italic / regular >> font and font size >> color >> subscript / superscript >> >> On 8/9/15, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: >>> And talking about DOCX generation: it looks like the hardest part is to >>> implement *model*. DOCX generation is boring but straightforward. >>> >>> Can you try to implement/describe such a model? >>> >>> 2015-08-08 22:25 GMT+03:00 Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com>: >>> >>>> Sorry if I was crude - it was not my intention :) >>>> I just spotted your question and have started investigation, and I just >>>> wanted to show that I'm in process of answering and answer will soon be >>>> here. Unfortunately, unexpected emergency happened...well, anyway: >>>> >>>> Using of TabularExperimenting is very simple (though not very usable): >>>> >>>> tab := TabularExperimenting new. >>>> tab generateXLSX. >>>> >>>> It will generate file named "Test.xlsx" in the current directory (in >>>> windows environment it is directory same to image one in most cases, in >>>> ubuntu it's home folder of the current user). >>>> >>>> If you'll see closely on TabularExperimenting, the model for the export >>>> is >>>> genrated in #initialize method. And, as far as I remember, it do not >>>> support multi-sheets documents (only first sheet will be actually >>>> written >>>> to the file). That's why it's Experimenting, not Exporter :) >>>> >>>> Well, I have used this code in production, making very quick, dirty and >>>> obvious API for this TabularExperimenting class. It's on repo now, but >>>> not >>>> recommended for loading (see the version comments to find one if you >>>> want >>>> to see it). >>>> >>>> >>>> >>>> >>>> 2015-08-08 13:32 GMT+03:00 H. Hirzel <hannes.hirzel(a)gmail.com>: >>>> >>>>> Sorry I do not want to put you under pressure, the second email was >>>>> just meant as a clarificiation of the first :-), take you time. >>>>> >>>>> --HH >>>>> >>>>> On 8/8/15, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: >>>>> > Give me couple of minutes to make answer, please. >>>>> > >>>>> > 2015-08-08 13:14 GMT+03:00 H. Hirzel <hannes.hirzel(a)gmail.com>: >>>>> > >>>>> >> Mainly the answer to the question: How do I use the experimental >>>>> exporter >>>>> >> class? >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> On 8/8/15, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>>>> >> > Yes, this is what I realized when looking at your code in >>>>> >> > Tabular. >>>>> >> > >>>>> >> > This is a good basis to build upon. I started adding some >>>>> >> > versions >>>>> >> > to >>>>> >> > http://ss3.gemtalksystems.com/ss/Tabular.html >>>>> >> > >>>>> >> > mainly adding comments and grouping method into protocols. >>>>> >> > >>>>> >> > Your test cases are useful. >>>>> >> > >>>>> >> > May I ask you to add some comment to the exporters subpackage? >>>>> >> > >>>>> >> > Hannes >>>>> >> > >>>>> >> > >>>>> >> > On 8/8/15, Vincent BLONDEAU <vincent.blondeau(a)polytech-lille.net> >>>>> >> > wrote: >>>>> >> >> I think you can improve Tabular to generate DOCX files. It is >>>>> >> >> the >>>>> same >>>>> >> >> file >>>>> >> >> standard than XLSX. >>>>> >> >> >>>>> >> >> Vincent >>>>> >> >> >>>>> >> >> -----Message d'origine----- >>>>> >> >> De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De >>>>> >> >> la >>>>> >> part >>>>> >> >> de >>>>> >> >> H. Hirzel >>>>> >> >> EnvoyÃ© : samedi 8 aoÃ»t 2015 08:56 >>>>> >> >> Ã : Any question about pharo is welcome >>>>> >> >> Objet : Re: [Pharo-users] MSOffice DOCX generation? >>>>> >> >> >>>>> >> >> I found Tabular >>>>> >> >> >>>>> >> >> http://ss3.gemtalksystems.com/ss/Tabular.html >>>>> >> >> >>>>> >> >> which is for Spreadsheets files. It is useful as an example for >>>>> >> >> creating >>>>> >> >> something similar for DOCX files. >>>>> >> >> >>>>> >> >> On 8/8/15, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>>>> >> >>> A similar library but for Java >>>>> >> >>> >>>>> >> >>> http://www.docx4java.org/trac/docx4j >>>>> >> >>> >>>>> >> >>> On 8/7/15, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>>>> >> >>>> Hello >>>>> >> >>>> >>>>> >> >>>> Is there a library like for Pharo to generate DOCX files? >>>>> >> >>>> >>>>> >> >>>> Something like this >>>>> >> >>>> https://docx.codeplex.com/ >>>>> >> >>>> DocX is a .NET library that allows developers to manipulate >>>>> >> >>>> Word >>>>> >> >>>> 2007/2010/2013 files, in an easy and intuitive manor. DocX is >>>>> fast, >>>>> >> >>>> lightweight and best of all it does not require Microsoft Word >>>>> >> >>>> or >>>>> >> >>>> Office to be installed. >>>>> >> >>>> >>>>> >> >>>> Regards >>>>> >> >>>> >>>>> >> >>>> Hannes >>>>> >> >>>> >>>>> >> >>> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> > >>>>> >> >>>>> >> >>>>> > >>>>> >>>>> >>>> >>> >> >

Aug. 24, 2015

Re: [Pharo-users] [ANN] Pharo Consortium New Gold Member: Projector Software GmbH

by Ben Coman

On Mon, Aug 24, 2015 at 6:37 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > The Pharo Consortium is very happy to announce that Projector Software GmbH > has joined the Consortium as an Gold Member. > > About > - Projector Software GmbH: http://projector.de > - Pharo Consortium: http://consortium.pharo.org > > The goal of the Pharo Consortium is to allow companies and institutions to > support the ongoing development and future of Pharo. > > Individuals can support Pharo via the Pharo Association: > > http://association.pharo.org > > Nice to hear. Slowly but surely building commercial support for Pharo. cheers -ben

Aug. 24, 2015

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo Consortium New Gold Member: Projector Software GmbH

by Norbert Hartl

Great!! Norbert > Am 24.08.2015 um 12:37 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > > > The Pharo Consortium is very happy to announce that Projector Software GmbH > has joined the Consortium as an Gold Member. > > About > - Projector Software GmbH: http://projector.de > - Pharo Consortium: http://consortium.pharo.org > > The goal of the Pharo Consortium is to allow companies and institutions to > support the ongoing development and future of Pharo. > > Individuals can support Pharo via the Pharo Association: > > http://association.pharo.org > >

Aug. 24, 2015

Re: [Pharo-users] issue with large file path on windows

by Henrik Johansen

> On 23 Aug 2015, at 6:09 , Nicolai Hess <nicolaihess(a)web.de> wrote: > > And If you want to review the changes: > > https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-lo… <https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-lo…> > > > 2015-08-23 13:44 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>>: > For those who had problems with pharo on windows and github based repositories, > I built a windows vm with support for long paths: > > https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari… <https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari…> > > > For browsing directories with large paths (FileList or Inspect), > you may need one additional change in the image (But I am not really sure about that) : > > DiskStore>>initialize > super initialize. > maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ]. > > > please test and give feedback. > > This wasn't as easy as I thought, and I had to make some more changes > for the file permissions (the stat-functions don't work for files with long paths). > Please test other file/folder operations. > > > nicolai > > > > + #define CONVERT_MULTIBYTE_TO_WIDECHAR_PATH(buffer, size, fileNameString, fileNameLength) { \ + buffer = (WCHAR*)alloca((size+4+1)*sizeof(WCHAR));\ + buffer[0] = L'\\';buffer[1] = L'\\'; buffer[2] = L'?'; buffer[3] = L'\\';\ + MultiByteToWideChar(CP_UTF8, 0, fileNameString, fileNameLength, buffer + 4, size);\ + buffer[size + 4] = 0;\ + size += 4;} - Is an alloca version really worth it for the potential problems? - Also, LONG_PATH_PREFIX_SIZE is defined above in the header, should probably use this instead of 4 in the last two lines? - The comment on lines 111/164/265/381, while not modified, are somewhat incorrect, null-terminated C-string indicates UTF8, which we are converting from, not into. I'm curious what the "\\?\ <smb://?/>" prefix does to hasCaseSensitiveDuplicate (adding a new ? segment to the path), but I cba to understand that code, and considering int caseSensitiveFileMode = 0; if(!caseSensitiveFileMode) return 0; I guess it doesn't really matter. Otherwise, looks good to me! Cheers, Henry

Aug. 24, 2015

Re: [Pharo-users] [ANN] Pharo Consortium New Gold Member: Projector Software GmbH

by Sven Van Caekenberghe

Excellent news! > On 24 Aug 2015, at 12:37, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > The Pharo Consortium is very happy to announce that Projector Software GmbH > has joined the Consortium as an Gold Member. > > About > - Projector Software GmbH: http://projector.de > - Pharo Consortium: http://consortium.pharo.org > > The goal of the Pharo Consortium is to allow companies and institutions to > support the ongoing development and future of Pharo. > > Individuals can support Pharo via the Pharo Association: > > http://association.pharo.org > >

Aug. 24, 2015

[ANN] Pharo Consortium New Gold Member: Projector Software GmbH

by Marcus Denker

The Pharo Consortium is very happy to announce that Projector Software GmbH has joined the Consortium as an Gold Member. About - Projector Software GmbH: http://projector.de - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

Aug. 24, 2015

SIXX in Pharo 4.0?

by H. Hirzel

Hello I experience a load problem of SIXX * in Pharo 4.0. https://github.com/mumez/SIXX/issues/2 The complaint is that a class ContextPart is not found. Any suggestions/hints how to proceed? Regards Hannes ----------------- * Smalltalk Instance eXchange in XML https://github.com/mumez/SIXX http://www.mars.dti.ne.jp/~umejava/smalltalk/sixx/index.html

Aug. 24, 2015