- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Artefact - a PDF framework
by Stephan Eggermont May 4, 2012

May 4, 2012

Why do we have so many ways to create pdfs, and why do most libraries/frameworks only provide a partial solution? At first it seems not to difficult to build something for what I need, so it makes sense to build it myself. But the pdf spec is large, and I don't use most of it. Building it myself makes more sense than trying to understand a current implementation. That is more complex than needed to solve the current problem, and building my own is a good way to understand the spec. Completing an implementation is hard to justify on project costs (as is mostly done for open source). More people seem to have followed the same road, so we end up with lots of partial solutions. Next time I need to create pdfs, I have different needs. Something with fonts, that seems like a lot of work. So I connect to a c library that already implements it. Only that has no way to create a document in-memory, just on diskâ¦ Artefact at the moment has very simple text layout and table algorithms. They are suitable for simple documents. High quality layout is complex as it needs to handle a.o. line breaking, justification, ligatures, kerning, hyphenation, text direction, text container shape, paragraph and page layout. PDF4Smalltalk is large because it is able to read and write pdfs, so it needs to have at least basic support for all pdf elements, and it contains lots of constants and mappings (glyph list, font metrics). Cairo (and Pango) by itself does not support reading pdfs. Stephan

1 0

[Pharo-project] [update 1.4] #14441
by Esteban Lorenzano May 4, 2012

May 4, 2012

14441 ----- Issue 5445: Broken command-line arguments in 1.4 http://code.google.com/p/pharo/issues/detail?id=5445 (this is to enable running pharo tests in windows)

1 0

[Pharo-project] [update 2.0] #20049
by Marcus Denker May 4, 2012

May 4, 2012

20049 ----- Issue 5751: SUnit-UI Interaction refactor http://code.google.com/p/pharo/issues/detail?id=5751 Issue 5445: Broken command-line arguments in 1.4 http://code.google.com/p/pharo/issues/detail?id=5445 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [update 2.0] #20045
by Marcus Denker May 4, 2012

May 4, 2012

20045 ----- Issue 5801: remove #testLiteralsForGlobalBehaviorsAreCorrect http://code.google.com/p/pharo/issues/detail?id=5801 Issue 5758: Improve CommandLine handling http://code.google.com/p/pharo/issues/detail?id=5758 -- Marcus Denker -- http://marcusdenker.de

3 2

[Pharo-project] [update 2.0] #20048
by Marcus Denker May 4, 2012

May 4, 2012

20048 ----- Issue 5793: More flexible special objects array http://code.google.com/p/pharo/issues/detail?id=5793 Issue 5802: Clean Embedded Temp Names: CompiledMethodTrailer http://code.google.com/p/pharo/issues/detail?id=5802 Issue 5791: Merge ExpandedSourceFileArray into SourceFileArray (part3: remove ExpandedSourceFileArray) http://code.google.com/p/pharo/issues/detail?id=5791 -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] [update 2.0] #20046
by Marcus Denker May 4, 2012

May 4, 2012

On May 4, 2012, at 1:30 PM, Sean P. DeNigris wrote: > > Marcus Denker-4 wrote >> >> Issue 5795: Merge System-BreakPoints with Tools-Debugger >> http://code.google.com/p/pharo/issues/detail?id=5795 >> > > Does this, by chance, take care of the problem where you add a breakpoint in > the Senders browser, and then it is not recognized by the Debugger? > No, I just moved the class around... Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [update 2.0] #20046
by Marcus Denker May 4, 2012

May 4, 2012

20046 ----- Issue 5789: Merge ExpandedSourceFileArray into SourceFileArray (part1 copy methods) http://code.google.com/p/pharo/issues/detail?id=5789 Issue 5804: Failing Test:testCommandLineHandlerCondition http://code.google.com/p/pharo/issues/detail?id=5804 Issue 5795: Merge System-BreakPoints with Tools-Debugger http://code.google.com/p/pharo/issues/detail?id=5795 -- Marcus Denker -- http://marcusdenker.de

2 2

[Pharo-project] [update 2.0] #20047
by Marcus Denker May 4, 2012

May 4, 2012

20047 ----- Issue 5782: Close ALL windows, no matter if they have unchanged changes http://code.google.com/p/pharo/issues/detail?id=5782 Issue 5792: Fix tempNamed and tempNamedPut http://code.google.com/p/pharo/issues/detail?id=5792 Issue 5790: Merge ExpandedSourceFileArray into SourceFileArray (part2 install and fix tests) http://code.google.com/p/pharo/issues/detail?id=5790 -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] #getSource is broken for temp names
by Marcus Denker May 4, 2012

May 4, 2012

On May 4, 2012, at 11:19 AM, Mariano Martinez Peck wrote: > > I don't know. In Fuel we have tests for each kind of trailer, included those which store temp names. > If this kind of trailer is not supported any more, I can remove the tests. > Yes! > If you want to remove temp names, then I think we still need to remove: > > #hasTempNames > #encodeTempsNamesQCompress > #encodeTempsNamesZip > #encodeUsingQCompress > #encodeUsingZip > #tempNames > #tempNames: > #decodeTempsNamesQCompress > #decodeTempsNamesZip > > remove the trailer type from #trailerKinds > Yes. One step at a time. Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] #getSource is broken for temp names
by Marcus Denker May 4, 2012

May 4, 2012

On May 4, 2012, at 11:03 AM, Mariano Martinez Peck wrote: > | trailer materializedCompiledMethod method | > > trailer := CompiledMethodTrailer new tempNames: 'param1 param2 temp1 temp2'. > self assert: trailer kind = #TempsNamesQCompress. > self assert: trailer kindAsByte = 8. > method := (self class >> #fooWith:and:) copyWithTrailerBytes: trailer. > self assert: (method getSource includesSubString: 'param1'). > > > this last assert fails. > > Problem is that #getSource is broken and somehow it looks like if the part of tempNames was removed. I propose to put back its original verison or just add at the beginning: > > trailer tempNames ifNotNil: [:namesString | > "Magic sources -- decompile with temp names" > ^ ((class decompilerClass new withTempNames: namesString) > decompile: selector in: class method: self) > decompileString]. > > > agree? if true I open an issue. No, the idea was to remove temp name embedding because it is not needed. Why do you need it? Marcus -- Marcus Denker -- http://marcusdenker.de

2 1