primordic/IssueDupesLite huggingface dataset:
Repository: google/accompanist

Issue #732: Remove Napier dependency
Created: 2021-09-21T12:44:32Z
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
The pager library depends on a logging library called Napier to log the current page when it changes. However the log is guarded by a boolean that is hardcoded to false. https://github.com/google/accompanist/blob/main/pager/src/main/java/com/google/accompanist/pager/Pager.kt#L51 So the dependency on napier that users of pager will get is completely unneeded.
Describe the solution you'd like
Remove the dependency. For a single log statement it's enough to use android.util.Log.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
You could also wrap it in a method that uses napier in the debug source set and is just empty in the release source set. That way the dependency could be changed to debug only.

Duplicate issue #1370: [Pager] Napier dependency in production classpath
Created: 2022-10-12T16:55:36Z
This is not really a bug, more a possible improvement.
With the removal of Android specific APIs in #402 Nappier was introduced solely for (hardcoded?) debug-logging in the pager library.
This in the ends effects the consumers release artifacts and Napier gets shipped for basically no reason. The raw size increase is only 24KB (without minification) but still this feels some kind of unnecessary.
Maybe it is possible to come up with an other logging approach or add a separate build type.

Closing comment (2023-05-22T12:55:38Z): Duplicate of #732. Unfortunately there is no progress.
Repository: google/accompanist

Issue #918: [System UI Controller] Preview is not rendering
Created: 2021-12-09T22:28:08Z
Preview started throwing an exception after commit bb866bf
java.lang.IllegalArgumentException: The Compose View must be hosted in an Activity with a Window!  at
com.google.accompanist.systemuicontroller.AndroidSystemUiController.<init>(SystemUiController.kt:177)   at
com.google.accompanist.systemuicontroller.SystemUiControllerKt.rememberSystemUiController(SystemUiController.kt:165)


  
    
      accompanist/systemuicontroller/src/main/java/com/google/accompanist/systemuicontroller/SystemUiController.kt
    
    
         Line 177
      in
      ce11b26
    
  
  
    

        
          
           private val window = requireNotNull(view.context.findWindow()) {

Duplicate issue #1138: [System UI Controller] Can't preview composables in version 0.23.1
Created: 2022-04-22T14:29:05Z
Description
Version 0.23.1 breaks composable previews
Steps to reproduce
Create a composable that uses rememberSystemUiController() and create a Preview for that composable
Expected behavior
Previews should be previewable 😄
Additional context
Stack trace in the screenshot below
⬇️

Closing comment (2022-04-22T17:28:27Z): Ah, it looks like the 1.1 branch had the version of code that didn't work with previews. This was also reported in #918 and fixed, but only on the 1.2 alpha branches.
Repository: google/accompanist

Issue #760: [PagerState] animateScrollToPage scroll to prev page not enought smooth
Created: 2021-10-01T13:05:29Z
Describe the bug
animateScrollToPage scroll to previous page sometimes critically not enough smooth. Looks like replacing, not scrolling.
How to reproduce
Open screen and click at Prev button several times.
Expected behavior
Smooth animated scrolling to previous page.
Environment:

Accompanist version: 0.19.0

@OptIn(ExperimentalPagerApi::class)
@Composable
fun IssueScreen() {
    val scope = rememberCoroutineScope()
    Column(Modifier.fillMaxSize()) {
        val pageCount = 10
        val startIndex = Int.MAX_VALUE / 2
        val state = rememberPagerState(initialPage = startIndex)
        HorizontalPager(
            modifier = Modifier.weight(1f),
            state = state,
            flingBehavior = PagerDefaults.flingBehavior(
                state = state,
                snapAnimationSpec = tween(500),
            ),
            count = Int.MAX_VALUE,
            key = { key -> key },
        ) { index ->
            val page = (index - startIndex).floorMod(pageCount)
            Box(
                modifier = Modifier.fillMaxSize().background(Color.Black),
                contentAlignment = Alignment.Center,
            ) {
                Box(modifier = Modifier.size(48.dp).background(Color.Magenta))
                Text(text = "$page",color = Color.White)
            }
        }
        Row(
            modifier = Modifier.fillMaxWidth().wrapContentHeight().padding(32.dp),
            horizontalArrangement = Arrangement.SpaceEvenly,
        ) {
            Button(
                onClick = {
                    scope.launch {
                        state.animateScrollToPage(state.currentPage-1)
                    }
                }
            ) {
                Text(modifier = Modifier.padding(16.dp), text = "Prev")
            }
            Button(
                onClick = {
                    scope.launch {
                        state.animateScrollToPage(state.currentPage+1)
                    }
                }
            ) {
                Text(modifier = Modifier.padding(16.dp), text = "Next")
            }
        }
    }
}

private fun Int.floorMod(other: Int): Int = when (other) {
    0 -> this
    else -> this - floorDiv(other) * other
}

Duplicate issue #923: [Pager] AnimateScrollToPage doesnt animate when targetPage < currentPage
Created: 2021-12-14T07:22:04Z
Description
The forward animation is always smooth, however when animating backwards (even if its just 1 page); it always snaps to the page.
Steps to reproduce
state.animateScrollToPage(0) when on page > 0 does the trick.

Closing comment (2021-12-14T13:10:53Z): Duplicate of #760
Repository: google/codeworld

Issue #1250: Pattern match failures give no hints about the errant value or call location
Created: 2019-12-12T23:47:12Z
Program: https://code.world/haskell#PbzAjsCnBebT4VmPRIGpp7g
Message:
program.hs:(26,1)-(27,29): Non-exhaustive patterns in function nth

Duplicate issue #1349: User-reported unhelpful error message
Created: 2020-05-15T18:45:54Z
Program: https://code.world/haskell#Pp8bM3w0rmTQy7MoJbQM1OA
Comment:
It doesnt tell me what to do
Message:
program.hs:49:1-59: Non-exhaustive patterns in function circles

Closing comment (2020-05-16T02:25:27Z): Dup of #1250
Repository: google/codeworld

Issue #1504: <<loop>> in Haskell mode
Created: 2021-05-09T20:29:07Z
Program: https://code.world/haskell#PTwiZEohkK037qoLmWOI3gA
Comment:
I want the loop!
Message:
<<loop>>

Duplicate issue #1529: User-reported unhelpful error message
Created: 2021-09-30T14:24:54Z
Program: https://code.world/haskell#P12fseRz8EIrA8hpq7DjDGw
Message:
<<loop>>

Closing comment (2021-09-30T15:31:34Z): Dup of #1504
Repository: google/codeworld

Issue #456: Better semantics for Picture
Created: 2017-03-31T07:54:30Z
I'd love to be able to say that Picture is semantically equivalent to Point -> Color.  Alas, it's not so.  For instance:

blank and colored(anything, RGBA(1, 1, 1, 0)) are identical in colors at each location; but colored(blank, red) is different from colored(colored(anything, RGBA(1, 1, 1, 0)), red).  This could be fixed with a rule that says that coloring a shape completely transparent causes it to forget its shape.
If a and b overlap, then colored(a & b, translucent(blue)) makes the region of overlap visible, even if it wasn't visible in a & b.  The right fix here is probably to declare that colored performs a sort of union of its first parameter using constructive area geometry (see #28), so that the overlap doesn't become visible.
Non-thick outline shapes like circle, rectangle, and polygon have weird behavior where their outlines stay 1 pixel wide regardless of scaling.  It's possible this could be rationalized as being just an artifact of rasterizing a perfectly thin line?  But it's mighty convenient.

The last point might stay the way it is... but I want to at least make an effort to get as close as possible to saying that Picture is just an abstract version of Point -> Color.

Duplicate issue #670: Color applied twice produces unexpected results
Created: 2018-06-21T02:52:54Z
This code will draw a blank output:
program = drawingOf(colored( colored(solidCircle(5), RGBA(0,0,0,0)), blue))
However, this code will draw a blue circle:
program = drawingOf(colored( colored(solidCircle(5), RGBA(0,0,0,0.001)), blue))
There is no apparent reason why colored is not continuous at (0,0,0,0)

Closing comment (2018-06-21T03:08:30Z): The idea is that Picture embeds into Point -> Color, which gives it a consistent denotational semantics.  But the semantics imply that colored(x, RGBA(r, g, b, 0)) should be the same as blank, since both pictures associate any point to a color that's completely transparent.  There are ways this could be handled such that colored is still continuous; for example, if colored multiplied alphas with the underlying image; but right now, what it tries to do is change any pixels with a non-transparent color to the new color.
By the way, I know these semantics don't actually work now.  The easiest counterexample is colored(a & b, translucent(c)) where a and b are overlapping opaque shapes.  I intend to fix that, and it's tracked in #456.
Repository: google/codeworld

Issue #1158: Students looking for LSU-specific modules on main CodeWorld site
Created: 2019-09-12T15:28:18Z
Program: https://code.world/#PMMCEenljwhO2B3bqshFwUg
Comment:
this is bugged
Message:
program.hs:4:1-22: error:
    Could not find module Lessons.Penguin

Duplicate issue #1161: User-reported unhelpful error message
Created: 2019-09-13T17:57:28Z
Program: https://code.world/#PcXnACqjpI3iwffWe9AZTJg
Comment:
this site is HAVING PROBLEMS because it wont run and there are no errors
Message:
program.hs:1:1-21: error:
    Could not find module Standard.Debug

Closing comment (2019-09-13T21:58:17Z): Dup of #1158
Repository: google/codeworld

Issue #655: Switch to GHCJS 8.6
Created: 2018-06-10T12:02:41Z
It looks like we're at the inflection point where 8.2 (or even 8.4?) is more reliable than 8.0.  It would be a good idea to switch over later on this summer, before the new school term starts.
This means verifying that we don't get regressions in error messages.

Duplicate issue #724: GHCS bug in simple program
Created: 2018-08-30T19:02:09Z
Describe the bug
This appears to be a GHCJS bug, but I'm new here:
panic! (the 'impossible' happened)
  (GHCJS version 0.2.1, GHC version 8.0.2):
	initTc: unsolved constraints
  WC {wc_insol =
        [W] fromString_a2MX :: t_a2MW[tau:1] (CHoleCan: fromString)
        [W] concatenation_a2N6 :: t_a2N5[tau:1] (CHoleCan: concatenation)
        [W] toString_a2Ng :: t_a2Nf[tau:1] (CHoleCan: toString)
        [W] toString_a2Np :: t_a2No[tau:1] (CHoleCan: toString)}

Please report this as a GHCJS bug:  https://github.com/ghcjs/ghcjs/issues


Shared Program
If you have a program that demonstrates what is wrong, add a link here from the "Share" button:

https://code.world/haskell#PpuTGVco91DpCgxUkW_DqkQ

Details

What browser are you using? Firefox/Vivaldi
What operating system are you using? Ubuntu 18.04

Additional context
This was a fairly quick port from regular code world code; maybe I overlooked something

Closing comment (2018-09-03T01:07:40Z): To quickly follow up, it looks like three things are necessary to trigger this bug.

There must be no definition of main (or program in CodeWorld mode).
There must be an explicit type signature on a declaration.
The declaration must use a variable that's not in scope.

The first and third are both independent errors, so it requires two separate errors to trigger this bug.  Nice to fix, but not a big deal.  I'll close this as a duplicate of #655.
Repository: google/codeworld

Issue #681: The time-step elision optimization is broken
Created: 2018-07-01T14:20:59Z
We broke time-step ellision for interactions somewhere.  See https://code.world/haskell#PPUTRWUDaX3tF9KMQYGTS-w

Duplicate issue #422: Paused animations still spin in idle loop
Created: 2017-01-14T20:46:26Z
When an animation is paused, we'd like the StableName sharing detection to stop spinning in a busy loop.  Looks like this doesn't happen, though.

Closing comment (2018-07-24T18:37:50Z): This is now a dup of #681, which covers a bigger problem.  Unfortunately, step ellision seems to be a very fragile thing.
Repository: google/codeworld

Issue #617: Students can't save programs when size or undo history is too long
Created: 2018-05-04T06:49:47Z
Sample error from web logs:
A web handler threw an exception. Details:
data/codeworld/projects/108731307630137615504/SrT/SrTcLcpDdPZeAa2roBRfzdg.cw: openBinaryFile: resource busy (file is locked)

It looks like the affected projects usually have very, very long undo history; I have seen up to 1MB project files (a few 10s of K of source, and a megabyte of undo history).  It might be wise to trim undo history when saving.

Duplicate issue #763: Saving projects with long undo history is still broken
Created: 2018-10-25T14:21:59Z
I once again ran into a situation where saving a project failed consistently with a 413 ("Request Entity Too Large") status code.  I really need to drastically increase this limit, but it seems to be baked in somewhere.

Closing comment (2019-02-22T04:17:12Z): Duplicate of #617
Repository: google/codeworld

Issue #1504: <<loop>> in Haskell mode
Created: 2021-05-09T20:29:07Z
Program: https://code.world/haskell#PTwiZEohkK037qoLmWOI3gA
Comment:
I want the loop!
Message:
<<loop>>

Duplicate issue #1505: User-reported unhelpful error message
Created: 2021-05-14T13:55:58Z
Program: https://code.world/haskell#Py_3eulgxMuGtS7pvHpUZuQ
Message:
<<loop>>

Closing comment (2021-05-14T14:05:45Z): dup #1504
Repository: google/codeworld

Issue #1105: Color deprecations should give exact replacements
Created: 2019-08-28T13:37:55Z
Program: https://code.world/#PIQEQG9nqW4TKu_atKLQ2xQ
Message:
program.hs:2:43-52: warning:
    In the use of aquamarine
    (defined in the standard library):
    "Please use RGB(...) instead of aquamarine.
     The variable aquamarine may be removed July 2020."

Duplicate issue #1127: User-reported unhelpful error message
Created: 2019-08-28T20:45:24Z
Program: https://code.world/#Pys7bkvz4kb2qluPS1M6CFw
Comment:
It's not helpful if you do not show me what I coded and just show me what could possibly be removed in the future.
Message:
program.hs:5:32-41: warning:
    In the use of chartreuse
    (defined in the standard library):
    "Please use RGB(...) instead of chartreuse.
     The variable chartreuse may be removed July 2020."

Closing comment (2019-08-28T21:13:44Z): Duplicate of #1105
Repository: google/codeworld

Issue #1009: Split CW.Driver into smaller modules
Created: 2019-06-21T00:19:10Z
Surely not all the things need to live in the same file.

Duplicate issue #493: Factoring the code in codeworld/codeworld-api/src/CodeWorld/Driver.hs
Created: 2017-06-04T04:49:13Z
Hi,
I noticed the two code branches in codeworld/codeworld-api/src/CodeWorld/Driver.hs where alot of the code is essentially identical upto the fact that in the client-side version runs in the IO monad while in the server-side version - the code runs in the Canvas monad from Graphics.Blank.
I'd propose defining a new Monad class instead, e.g.
class (Monad m) => CanvasMonad m
    moveTo :: Point -> m ()
    lineTo :: Point -> m ()
    -- and so on ...

For the server side version, there would be an instance
instance CanvasMonad Canvas where
    moveTo = Canvas.moveTo
    lineTo = Canvas.lineTo
    -- and so on ...

and on the client side
instance CanvasMonad IO where
    -- definition as above 

That would reduce the code duplication considerably.
I can send a Pull Request myself, but wanted to get an opinion first.
What do you think?

Closing comment (2020-01-20T16:43:45Z): Work on remaining parts of this is now tracked in #1009.
Repository: google/glog

Issue #207: Failed to build glog with android ndk r11c using api 17 on 4.2.2
Created: 2017-07-08T07:55:42Z
I have successfully built glog with r11c using api 21 on 5.1 but when i want to move glog to older android version using api 17 on 4.2.2, i met these following errors:
logging.cc:`` In member function 'virtual void google::{anonymous}::LogFileObject::Write(bool, time_t, const char*, int)':
./glog/src/logging.cc:1157:46: error: 'POSIX_FADV_DONTNEED' was not declared in this scope
posix_fadvise(fileno(file_), 0, len, POSIX_FADV_DONTNEED);
^
./glog/src/logging.cc:1157:65: error: 'posix_fadvise' was not declared in this scope
posix_fadvise(fileno(file_), 0, len, POSIX_FADV_DONTNEED);
^
and i have known that this POSIX_FADV_DONTNEED is defined at fcntl.h and logging.cc have already included it.
Why it works with api 21 but doesn't work with api 17? Could anyone help me, thanks.

Duplicate issue #358: Cross Compile Error
Created: 2018-08-24T07:29:14Z
When I compile with arm-gcc 4.4,I add tag "-std=c++0x".
In file included from /home/eclipse-workspace/Push/src/base/Logging.h:17,
                 from Push.cpp:12:
/home/eclipse-workspace/Push/src/log/glog/logging.h: In function 'T google::CheckNotNull(const char*, int, const char*, T&&)':
/home/eclipse-workspace/Push/src/log/glog/logging.h:1333: error: 'nullptr' was not declared in this scope

GXX_EXPERIMENTAL_CXX0X is defined while the gcc version is smaller than 4.7

Closing comment (2020-08-06T06:29:32Z): Similar issue when I try to cross compile to mips_24kc with OpenWrt Imagebuilder:
src/symbolize_unittest.cc: In function 'int main(int, char**)':
src/symbolize_unittest.cc:410:3: error: 'TestWithPCInsideInlineFunction' was not declared in this scope
   TestWithPCInsideInlineFunction();
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/symbolize_unittest.cc:411:3: error: 'TestWithPCInsideNonInlineFunction' was not declared in this scope
   TestWithPCInsideNonInlineFunction();
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/symbolize_unittest.cc:412:3: error: 'TestWithReturnAddress' was not declared in this scope
   TestWithReturnAddress();
   ^~~~~~~~~~~~~~~~~~~~~

Similar to

#207
#104

glog: v0.4.0
gflags: v2.2.2

Same problem, have you solved it?
Repository: google/glog

Issue #38: Make error: failed to link with libgflags.a
Created: 2015-07-04T09:21:42Z
/bin/bash ./libtool  --tag=CXX   --mode=link g++    -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare  -DNO_FRAME_POINTER  -DNDEBUG -g -O2    -o libglog.la -rpath /usr/local/lib  src/libglog_la-logging.lo src/libglog_la-raw_logging.lo src/libglog_la-vlog_is_on.lo src/libglog_la-utilities.lo src/libglog_la-demangle.lo src/libglog_la-symbolize.lo src/libglog_la-signalhandler.lo   -lgflags  -lpthread 
libtool: link: g++  -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.9/crtbeginS.o  src/.libs/libglog_la-logging.o src/.libs/libglog_la-raw_logging.o src/.libs/libglog_la-vlog_is_on.o src/.libs/libglog_la-utilities.o src/.libs/libglog_la-demangle.o src/.libs/libglog_la-symbolize.o src/.libs/libglog_la-signalhandler.o   -lgflags -lpthread -L/usr/lib/gcc/x86_64-linux-gnu/4.9 -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.9/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o  -O2   -Wl,-soname -Wl,libglog.so.0 -o .libs/libglog.so.0.0.0
/usr/bin/ld: //usr/local/lib/libgflags.a(gflags.cc.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
//usr/local/lib/libgflags.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:1041: recipe for target 'libglog.la' failed
make: *** [libglog.la] Error 1

note that it searches for the library at
//usr/local/lib/libgflags.a

Duplicate issue #45: make error
Created: 2015-07-31T11:03:35Z
I am getting the following error, while running make:
/usr/bin/ld: /usr/local//lib/libgflags.a(gflags.cc.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
How to fix it?

Closing comment (2015-12-17T07:48:35Z): Duplicate of #38 ?
Repository: google/glog

Issue #52: ./configure && make && make install fails with error: expected initializer before 'Demangle'
Created: 2015-08-24T20:15:43Z
The error is below.  I see the same problem referenced in #7, though it's not clear to me from the discussion whether this issue is fixed, and the instructions still direct users to use ./configure && make && make install.
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I./src -I./src -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -DNO_FRAME_POINTER -DNDEBUG -g -O2 -MT src/libglog_la-demangle.lo -MD -MP -MF src/.deps/libglog_la-demangle.Tpo -c src/demangle.cc  -fPIC -DPIC -o src/.libs/libglog_la-demangle.o
In file included from src/demangle.cc:38:0:
src/demangle.h:80:27: error: expected initializer before 'Demangle'
 bool GOOGLE_GLOG_DLL_DECL Demangle(const char *mangled, char *out, int out_size);
                           ^

Duplicate issue #70: "make install" failure
Created: 2015-11-18T08:00:45Z
environment:
uname -a
Linux localhost.localdomain 3.10.0-229.11.1.el7.x86_64 #1 SMP Thu Aug 6 01:06:18 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
make && make install
src/demangle.h:80:27: error: expected initializer before 'Demangle'
bool GOOGLE_GLOG_DLL_DECL Demangle(const char *mangled, char *out, int out_size);
^
make: *** [src/libglog_la-demangle.lo] Error 1

Closing comment (2015-12-17T07:39:57Z): Duplicate of #52
Repository: google/glog

Issue #45: make error
Created: 2015-07-31T11:03:35Z
I am getting the following error, while running make:
/usr/bin/ld: /usr/local//lib/libgflags.a(gflags.cc.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
How to fix it?

Duplicate issue #38: Make error: failed to link with libgflags.a
Created: 2015-07-04T09:21:42Z
/bin/bash ./libtool  --tag=CXX   --mode=link g++    -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare  -DNO_FRAME_POINTER  -DNDEBUG -g -O2    -o libglog.la -rpath /usr/local/lib  src/libglog_la-logging.lo src/libglog_la-raw_logging.lo src/libglog_la-vlog_is_on.lo src/libglog_la-utilities.lo src/libglog_la-demangle.lo src/libglog_la-symbolize.lo src/libglog_la-signalhandler.lo   -lgflags  -lpthread 
libtool: link: g++  -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.9/crtbeginS.o  src/.libs/libglog_la-logging.o src/.libs/libglog_la-raw_logging.o src/.libs/libglog_la-vlog_is_on.o src/.libs/libglog_la-utilities.o src/.libs/libglog_la-demangle.o src/.libs/libglog_la-symbolize.o src/.libs/libglog_la-signalhandler.o   -lgflags -lpthread -L/usr/lib/gcc/x86_64-linux-gnu/4.9 -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.9/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o  -O2   -Wl,-soname -Wl,libglog.so.0 -o .libs/libglog.so.0.0.0
/usr/bin/ld: //usr/local/lib/libgflags.a(gflags.cc.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
//usr/local/lib/libgflags.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:1041: recipe for target 'libglog.la' failed
make: *** [libglog.la] Error 1

note that it searches for the library at
//usr/local/lib/libgflags.a

Closing comment (2015-10-27T21:02:50Z): Similar to #45.
gflags is not compiled as a shared library by default; make sure it is compiled as a shared library:
cd gflags/build
cmake .. -DBUILD_SHARED_LIBS=ON
make -j2
sudo make -j2 install
After that glog compiles fine against gflags.
Repository: google/glog

Issue #823: compile fail
Created: 2022-04-26T06:31:20Z
glog-0.6.0/src/base/commandlineflags.h:127:16: error: expected constructor, destructor, or type conversion before '(' token
127 |   DEFINE_uint32(name, EnvToUInt("GLOG_" #name, value), meaning)
glog-0.6.0/src/logging.cc:194:1: note: in expansion of macro 'GLOG_DEFINE_uint32'
[ 23%] Building CXX object CMakeFiles/glogbase.dir/src/signalhandler.cc.o
CMakeFiles/glogbase.dir/build.make:94: recipe for target 'CMakeFiles/glogbase.dir/src/logging.cc.o' failed

Duplicate issue #1113: build failed with clang-19
Created: 2024-07-16T15:03:34Z
I am following the build instruction in Google Logging Library.
The cmake command is
cmake -DCMAKE_CXX_COMPILER=clang++-19 -S . -B build -G "Unix Makefiles"
then the build command generated the following error:

Does anyone know how to fix it?

Closing comment (2024-07-16T15:58:23Z): Thanks for the report.
Are you suggesting that the issue is specific to clang 19 and does not occur with a different compiler?
I believe the problem is rather similar to #823 and is in fact unrelated to clang 19.
Repository: google/glog

Issue #52: ./configure && make && make install fails with error: expected initializer before 'Demangle'
Created: 2015-08-24T20:15:43Z
The error is below.  I see the same problem referenced in #7, though it's not clear to me from the discussion whether this issue is fixed, and the instructions still direct users to use ./configure && make && make install.
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I./src -I./src -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -DNO_FRAME_POINTER -DNDEBUG -g -O2 -MT src/libglog_la-demangle.lo -MD -MP -MF src/.deps/libglog_la-demangle.Tpo -c src/demangle.cc  -fPIC -DPIC -o src/.libs/libglog_la-demangle.o
In file included from src/demangle.cc:38:0:
src/demangle.h:80:27: error: expected initializer before 'Demangle'
 bool GOOGLE_GLOG_DLL_DECL Demangle(const char *mangled, char *out, int out_size);
                           ^

Duplicate issue #108: src/demangle.h:80:27: error: expected initializer before 'Demangle' bool GOOGLE_GLOG_DLL_DECL Demangle(const char *mangled, char *out, int out_size);
Created: 2016-05-06T00:58:44Z
ibtool: compile:  g++ -DHAVE_CONFIG_H -I. -I./src -I./src -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -DNO_FRAME_POINTER -DNDEBUG -g -O2 -MT src/libglog_la-demangle.lo -MD -MP -MF src/.deps/libglog_la-demangle.Tpo -c src/demangle.cc  -fPIC -DPIC -o src/.libs/libglog_la-demangle.o
In file included from src/demangle.cc:38:0:
**src/demangle.h:80:27: error: expected initializer before 'Demangle'
bool GOOGLE_GLOG_DLL_DECL Demangle(const char mangled, char out, int out_size);
^
make: *** [src/libglog_la-demangle.lo] 错误 1
[root@localhost glog]#

Closing comment (2016-06-23T18:45:50Z): seems like this is a dup of #52
Repository: google/go-cloud

Issue #1328: pubsub: subscribing queues to topics on AWS conformance tests is broken
Created: 2019-02-14T19:19:55Z
See aws/aws-sdk-go#2415. That issue has a response with a possible solution.

Duplicate issue #1447: pubsub: AWS driver hangs if Receive is called before Send
Created: 2019-03-04T22:23:11Z
This is reproducible using #1446:
[ ~/src/gocloud.dev/pubsub/awspubsub ] time go test -record -v -run 'TestConformance/TestSendReceive\b'
=== RUN   TestConformance
=== RUN   TestConformance/TestSendReceive
--- PASS: TestConformance (1.92s)
    --- PASS: TestConformance/TestSendReceive (1.91s)
        setup.go:103: Recording into golden file testdata/TestConformance/TestSendReceive.replay
PASS
ok      gocloud.dev/pubsub/awspubsub    2.168s

real    0m4.157s
user    0m1.754s
sys     0m0.878s
[ ~/src/gocloud.dev/pubsub/awspubsub ] time go test -record -v -run 'TestConformance/TestReceiveSend'
=== RUN   TestConformance
=== RUN   TestConformance/TestReceiveSend
^Csignal: interrupt
FAIL    gocloud.dev/pubsub/awspubsub    40.802s

real    0m42.793s
user    0m2.415s
sys     0m1.122s

Closing comment (2019-03-04T23:48:56Z): This appears to be a duplicate of #1328.
Repository: google/go-cloud

Issue #2: blob: no way to distinguish non-existent blob
Created: 2018-05-11T16:12:33Z
For both Delete and NewReader, there's no way to distinguish blob-not-found from a normal error. This is useful for serving 404 instead of 500.
/cc @shantuo

Duplicate issue #304: blob/gcsblob: ContentType "form-data; name=foo" is not supported
Created: 2018-08-10T16:45:32Z
If you try to Write to a blob with ContentType set to "form-data; name=foo", it fails with:
googleapi: Error 400: Media type 'form-data; name=foo' is not supported. Valid media types: [/], badContent
This works for AWS.
Fix for GCS, or figure out how to document/deal with deltas in what ContentTypes are supported.

Closing comment (2018-08-11T03:15:12Z): Agree that we need to come up with an overall strategy for how to deal with provider differences. Some options include:

Enforce the most restrictive constraints in the API. This results in true portability, but less flexibility.
Don't do anything, and just document places where we are allowing anything through the API, but know that different providers have different rules.
Same as #2, but try to document all of the differences.
Same as #1, but just warn or provide some other way of letting the API user know that if they switch to a different provider implementation, the behavior may change.
Repository: google/go-cloud

Issue #629: all: design proposal for how to introduce metrics and tracing into APIs
Created: 2018-11-06T22:10:49Z
E.g., blob should export some basic, opencensus metrics and allow debug logging to be enabled.
Questions include:

What should be in the concrete type vs in driver implementations.
Should we even log? (some argue that libraries shouldn't log at all).
What's the right way to enable logging? Printf like function in Options? An interface provided in Options? log.Printf?
What metrics should [blob, runtimevar, pubsub] export?

Duplicate issue #713: pubsub/gcppubsub: allow logging of pull errors
Created: 2018-11-15T17:52:30Z
Quoting @zombiezen , in his review of #705, referring to the call to s.client.Pull(ctx, req):

Unfortunately, this error will never get seen by the end user, but it could be helpful for debugging. We could add a hook to the constructor to the effect of:
// A type that implements ErrorLogger reports errors that occur while receiving a batch.
type ErrorLogger interface {
  LogError(context.Context, error)
}
(Probably with some filtering for transient errors or such.)

Closing comment (2018-11-21T04:15:28Z): Closing as a dup of #629 for now. If we find that this really needs to be handled as a special case we can reopen it.
Repository: google/go-cloud

Issue #1174: all: add open-by-name functions to all APIs
Created: 2019-01-24T17:32:48Z
(This grew out of #931 and is now a larger effort, so opening a bigger-scoped issue.)
A very common use case when developing a portable application is to want to use a local implementation for development and then use the real implementation in production. Commonly, developers don't want to have two different build configurations to do this: they just want to be able to change by command-line flag. Right now, this is difficult to do: every application using Go Cloud would have to develop their own mechanism for specifying which provider resource they want to use. (This would be similar to SQL connection strings, but I think we want to keep credentials explicitly passed.)
I'm going to iterate on the blob URL-opening API, and once that gets to a place we're happy with, then I'd like to duplicate the API for our other portable APIs (pub/sub, secrets, runtimevar, and SQL).

Duplicate issue #917: runtimevar: add a WatchURL similar to blob
Created: 2018-12-07T19:45:42Z
E.g., instead of:
v := paramstore.NewClient(...).NewVariable("foo", stringDecoder, nil)
// v is a *runtimevar.Watcher

support
v := runtimevar.WatchURL("paramstore://foo?decoder=string")
// v is a *runtimevar.Watcher

Closing comment (2019-02-27T19:42:22Z): Dupe of #1174.
Repository: google/go-cloud

Issue #28: travis: only run affected tests on PR checks
Created: 2018-05-25T18:31:50Z
It would be nice to have PR Travis builds only run the tests for any affected packages for the files touched, then leave the master branch build to run all tests.  The benefit would be to decrease the presubmit latency, since running less tests also means less dependencies to download.  I'm not sure if this has been done before, but it seems like all the information is there in the Go tool and Travis to do subsetting like this.
/cc @cflewis

Duplicate issue #214: all: default should be to run only fast tests, opt in for slow and complicated tests
Created: 2018-07-20T22:44:33Z
At present, running vgo test ./... at the root takes 1m20s and outputs lots of failures if its dependencies have not been set up.
The current way to work around that is to add the -short flag mentioned in CONTRIBUTING.md, but it's easy to forget and seems like the reverse of how things should be arranged. Also, that still doesn't filter out the wire tests, and those take 40s to run on my laptop.
I suggest we use build tags to allow opting in to running progressively larger and more complicated tests. We could use the usual Google test size conventions for these. There would probably need to also be an additional, implicit size of tiny for the many test files that run in under 1s or so. Running only those tests would then be the default that happens when running vgo test ./....

Closing comment (2018-07-23T15:06:25Z): (This issue is related to #28 by way of test speed, but this is mostly about local development, not CI.)
Repository: google/go-cloud

Issue #970: all:  documenting design pattern for constructors and make packages consistent with it
Created: 2018-12-14T17:29:02Z
@jba
@zombiezen
We seem to have several patterns for how driver implementations expose their constructors. We should document our preference and aim for consistency unless there are good reasons for variance.

blob has OpenBucket at the top level. This seems simplest to me.
runtimevar/paramstore has a Client struct (here). Client then exposes NewVariable, which is how you get an instance of the concrete type.

I think we can just get rid of this intervening type and have NewVariable take whatever is being passed to NewClient.


pubsub/mempubsub has a Broker (here) and then NewTopic takes an instance of the Broker.

Duplicate issue #679: all: decide whether to have common Client types
Created: 2018-11-13T02:35:40Z
In a review for the pubsub design, @rsc pointed out that there is some boilerplate in the acmepubsub example given there, having to do with Client methods that create Topics and Subscriptions, and that it seems a bit strange to not have a Client type in the concrete pubsub API.
The blob package similarly has no Client type in its concrete API, so the same question applies to it. Let's discuss and see if Go Cloud should have standard Client types for these sorts of packages.

Closing comment (2018-12-17T19:31:58Z): Duplicate of #970.
Repository: google/go-cloud

Issue #2089: docstore: test mongo driver on Amazon DocumentStore
Created: 2019-05-14T20:14:07Z
Make sure we can use our mongoDB driver against Amazon DocumentStore. If necessary, add code to simplify the experience.

Duplicate issue #2122: docstore: support Amazon DocumentDB via MongoDB driver
Created: 2019-05-16T16:43:59Z
We should be able to use DocumentDB with our mongo driver. We should add that to our conformance tests.

Closing comment (2019-06-05T22:40:48Z): Dup of #2089.
Repository: google/go-cloud

Issue #410: server: add a `driver` field taking a to-be-defined `driver.Server`
Created: 2018-09-07T21:50:09Z
For some purposes such as running on App Engine, it may be useful to have the additional flexibility afforded by having a Driver field on server.Server, something like this:
type Server struct {
	reqlog        requestlog.Logger
	healthHandler health.Handler
	te            trace.Exporter
	sampler       trace.Sampler
	once          sync.Once
	server        *http.Server
	driver        driver.D  // <- Add this line
}

where server/driver.D is defined like this:
package driver 
type D inferface {
	func Serve(http.Handler)
}

Duplicate issue #408: server: refactor server with a driver
Created: 2018-09-07T21:34:08Z
server.Server.ListenAndServe creates an http.Server and calls ListenAndServe on it. The caller never gets access to the http.Server, so can't set any options on it.
#354 requests setting some options on the http.Server, which we could do, but I don't think it's a good idea to set a subset of options without giving the user the ability to override them or to set other options.
@zombiezen has suggested it server be refactored to:

Have a concrete type backed by a driver interface (similar to blob).
The driver would have a single method like Serve(http.Handler).
Server which would take the existing Options and do things like wrap the handler, etc.,
One implementation of the driver would be for http.Server. It would likely provide a static function to create an http.Server with default options, and then a constructor for the driver that takes the http.Server, thus allowing the caller to set additional options on it if needed.
There may be other implementations of the driver for AppEngine, etc. (#210 may be related).

Closing comment (2018-09-07T21:51:44Z): Dupe of #410
Repository: google/go-cloud

Issue #2133: docstore: limit ongoing RPC's when necessary
Created: 2019-05-17T00:28:15Z
When running benchmarks against the DynamoDB backend, I got errors like:
at XXX: RequestError: send request failed
        caused by: Post https://dynamodb.us-east-2.amazonaws.com/: dial tcp: lookup dynamodb.us-east-2.amazonaws.com: no such host;

I think this is because we have too many open request when doing the plenty of unordered actions. I'm running on macOS, which has a relative small default file descriptor limit so this is relatively easy to trigger.

Duplicate issue #2228: docstore: limit outstanding RPCs
Created: 2019-06-03T16:29:28Z
Since docstore providers sometimes issue concurrent RPCs, we should have a way to limit them. It would be nice if this could be at the docstore (portable) level.

Closing comment (2019-06-05T22:29:40Z): Dup of #2133.
Repository: google/gson

Issue #1778: NPE while invoke toJson() or fromJson() for HashMap<String, String> 
Created: 2020-09-11T08:27:27Z
the exception:
java.lang.NullPointerException: Attempt to invoke virtual method 'int java.lang.Object.hashCode()' on a null object reference
  libcore.reflect.TypeVariableImpl.hashCode(TypeVariableImpl.java:47)
  java.util.HashMap.hash(HashMap.java:338)
  java.util.HashMap.containsKey(HashMap.java:595)
  java.util.HashSet.contains(HashSet.java:203)
  com.google.gson.internal.$Gson$Types.resolve(.java:346)
  com.google.gson.internal.$Gson$Types.resolve(.java:381)
  com.google.gson.internal.$Gson$Types.resolve(.java:337)
  com.google.gson.internal.$Gson$Types.getSupertype(.java:283)
  com.google.gson.internal.$Gson$Types.getCollectionElementType(.java:302)
  com.google.gson.internal.bind.CollectionTypeAdapterFactory.create(CollectionTypeAdapterFactory.java:52)
  com.google.gson.Gson.getAdapter(Gson.java:458)
  com.google.gson.Gson.toJson(Gson.java:696)
  com.google.gson.Gson.toJson(Gson.java:683)
  com.google.gson.Gson.toJson(Gson.java:638)
  com.google.gson.Gson.toJson(Gson.java:618)

my code:
new Gson().fromJson(json, new TypeToken<HashMap<String, String>>() {}.getType());
environment
Gson version 2.8.5
The probability of this problem happens substantial increases，when gson version upgrades from 2.8.2 to 2.8.5 !
Same problem with #1298 , but not resolved.

Duplicate issue #2070: Occasional NullPointerException when calling Gson.fromJson when converting to a TypedToken of type CopyOnWriteArraySet
Created: 2022-02-03T03:54:43Z
Gson version
2.8.9
Java / Android version
Multiple Android versions (23+)
Description
NullPointerException when calling Gson.fromJson when converting to a TypedToken of type CopyOnWriteArraySet.
This crash is noticed on user devices but not reproducible locally while debugging.
Here is the code that is causing the null pointer.
        CopyOnWriteArraySet<String> result;
        Type type = new TypeToken<CopyOnWriteArraySet<String>>() {
        }.getType();
        Gson gson = new Gson();
        result = gson.fromJson(json, type);

Exception stack trace

Closing comment (2024-07-22T22:43:06Z): I am going to close this issue since this is likely a duplicate of #1778
Repository: google/gson

Issue #611: InstanceCreator not overwriting field values
Created: 2015-03-19T18:34:28Z
What steps will reproduce the problem?
1.Class that I am trying is serialize has an abstract class object as property
2.while deserializing I am registering instance creator to use object to above 
mentioned abstrcat class child
3.But is is not overwritting the values

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.


Original issue reported on code.google.com by mansiawa...@gmail.com on 19 Nov 2014 at 9:15

Duplicate issue #612: InstanceCreator not overwriting field values
Created: 2015-03-19T18:34:28Z
What steps will reproduce the problem?
1.Class to whom I ma trying to desrialize contain an abtract class object as 
property
2.so I registered instance creator for abstrcat class and asked to use child's 
object
but is not overwriting child value
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.


Original issue reported on code.google.com by mansiawa...@gmail.com on 19 Nov 2014 at 9:22

Closing comment (2022-07-25T19:30:57Z): Probably does not contain enough context to reproduce this, and might no longer be relevant given how old this issue is.
(Also looks like a duplicate of #611.)
Repository: google/gson

Issue #543: Abstract classes are not serialized when adding a Deserializer (TESTCASE)
Created: 2015-03-19T18:33:48Z
Here is the test-case: https://gist.github.com/fab1an/7532478

Original issue reported on code.google.com by fabian.z...@gmail.com on 18 Nov 2013 at 6:09

Duplicate issue #479: Adding deserializer for interfaces causes serialization to fail
Created: 2015-03-19T18:33:08Z
What steps will reproduce the problem?
1.Create a deserializer for an interface class and register it
2.Serialization of the interface no longer occurs.

What is the expected output? What do you see instead?
I expected to see the class serialized like it was before the deserializer was 
registered.


What version of the product are you using? On what operating system?
Using GSON version 2.1, on Windows 7 x64, using Oracle Java (32 bit) 7 update 3

Please provide any additional information below.

Here is a small example that will illustrate the issue (written as a JUnit 
test).


    public interface HelloInterface {
        public String sayHello();
    }

    public class HelloClass implements HelloInterface{
        private String hi = "hi";

        public String sayHello(){
            return hi;
        }
    }

    public class Greeter {

        private HelloInterface saysHello;

        public void setHello(HelloInterface hello){
            saysHello = hello;
        }

    }

    public void testGsonSerialization(){
        GsonBuilder builder = new GsonBuilder();
        Greeter greeter = new Greeter();
        final String expectedCorrect = "{\"saysHello\":{\"hi\":\"hi\"}}";
        final String incorrectJson = "{\"saysHello\":{}}";
        // Should be able to serialize, but not deserialize.
        greeter.setHello(new HelloClass());
        String jsonResult = builder.create().toJson(greeter);
        assertEquals(expectedCorrect, jsonResult);
        builder.registerTypeAdapter(HelloInterface.class, new JsonDeserializer<HelloInterface>() {

            @Override
            public HelloInterface deserialize(JsonElement json, Type typeOfT, JsonDeserializationContext context)
            throws JsonParseException {
                // Do stuff, it doesn't even matter here.
                return null;
            }
        });
        //Registering a deserializer causes the serialization to not work anymore.
        String secondJsonResult = builder.create().toJson(greeter);
        // This line passes.
        assertEquals(incorrectJson, secondJsonResult);
        // This line fails
        assertEquals(expectedCorrect, secondJsonResult);
    }

Original issue reported on code.google.com by mdkitz...@gmail.com on 9 Oct 2012 at 9:02

Closing comment (2022-07-23T22:57:55Z): Still the case in Gson 2.9.0, and seems to be the same as #543 / #2032.
Repository: google/gson

Issue #485: Let JsonElement implement Cloneable and Serializable
Created: 2015-03-19T18:33:12Z
the gson API is neither Serializable nor Cloneable. I'd imagine that both 
features should be relatively easy to implement...?

Original issue reported on code.google.com by lukas.eder@gmail.com on 8 Nov 2012 at 3:51

Duplicate issue #2697: Make com.google.gson.JsonElement Serializeable
Created: 2024-06-04T09:38:54Z
Problem solved by the feature
I develop an Application that uses RMI for some internal communication. Objects passed via RMI from one part of the application to another need to implement Serializeable, otherwise it wont work. It would be most convienient for me to be able to pass
JsonElement and its subclasses directly via RMI.
Feature description
Simply adding "implements Serializeable" to com.google.gson.JsonElement would solve my problem.
Alternatives / workarounds
Currently I have written a custom "String" wrapper class that is passed via RMI that indicates that the object is a json element.
The side sending the object has to call JsonElement#toString while the receive side has to parse the JsonElement again.
This is a bit cumbersome and needless in my opinion.
If you want to make it fancy.
You could implement java.io.Externalizable instead of Serializeable and write the data as Json over the RMI interface instead of using Javas Default Serialization facitilty. This would probably make it "faster", but require more effort compared to simply adding implements Serializeable to the class. For my use case this potencial performance gain is not required.

Closing comment (2024-06-05T21:30:14Z): Sounds like a duplicate of #485, so I am closing this issue here. Cloneable has been implemented through the custom deepCopy() method, but Serializable hasn't yet.
I am not sure why this hasn't been implemented yet, but maybe one reason is that this involves more than just marking the classes Serializable, but you then also have to guarantee that their serialization format remains the same over time.
Repository: google/gson

Issue #617: Serialization in order
Created: 2015-03-19T18:34:30Z
What steps will reproduce the problem?
1.I am using Gson library for serialization, In gson after serialization fields 
are not in order(I mean order however it was in that model class).But it gives 
some random order.


What is the expected output? What do you see instead?
I want Serialization to be done in that same order(fields order inside that 
model class)

What version of the product are you using? On what operating system?


Please provide any additional information below.

Original issue reported on code.google.com by harshith...@gmail.com on 30 Dec 2014 at 4:58

Duplicate issue #1880: How to set some property above after converting class to sting using toJson Method
Created: 2021-04-06T13:38:35Z
I have a screenshot class. and I doing serialization  Gson().toJson(objOfClass). but I need to set SEQ,& SRC property before the DEVAWSEP so how could I set it?
{"state":{"desired":{"ACT":1,"DEVAWSEP":"xxxxxxxxx","SEQ":6048799,"SRC":"MA"}}}
I want this form
{"state":{"desired":{"ACT":1,"SEQ":6048799,"SRC":"MA","DEVAWSEP":"xxxxxxxxx"}}}
so I want to do to serialization without alphabet order
ScreenShot of my class

Closing comment (2021-04-06T15:25:14Z): Sounds like this might be a duplicate of #617